Download GemBuilder for Smalltalk

Managing Transactions
Managing Concurrent Transactions
Read and Write Operations
It is customary to consider the operations that take place within a transaction as
reading or writing objects. Any operation that accesses any instance variable of an
object reads that object, as do operations that fetch an object’s size, class, or other
descriptive information about that object. An object also is read in the process of
being stored into another object.
An operation that stores a value in one of an object’s instance variables writes the
object. While you can read without writing, writing an object always implies
reading it, because GemStone must read the internal state of an object in order to
store a value in it.
In order to detect conflict among concurrent users, GemStone maintains two
logical sets for each session: a set containing objects read during a transaction and
a set containing objects written. These sets are called the read set and the write
set. Because writing implies reading, the read set is always a superset of the write
set.
The following conditions signal a possible concurrency conflict:
• An object in your write set is also in ananother transaction’s write set (a
write/write conflict).
• An object in your write set is in another transaction’s read set and an object in
your read set is in that transaction’s write set (a read/write conflict).
Optimistic and Pessimistic Concurrency Control
GemStone provides two approaches to managing concurrent transactions:
optimistic and pessimistic. An application can use either or both approaches, as
needed.
Optimistic concurrency control means that you simply read and write objects as if
you were the only session, letting GemStone detect conflicts with other sessions
only when you try to commit a transaction.
Pessimistic concurrency control means that you act as early as possible to prevent
conflicts by explicitly requesting locks on objects before you modify them. When
an object is locked, other users are unable to lock the object or commit changes to it.
Optimistic concurrency control is easy to implement in an application, but you run
the risk of having to re-do the work you’ve done if conflicts are detected and
you’re unable to commit. When GemStone looks for conflicts only at commit time,
your chances of being in conflict with other users increase with the time between
commits and the size of your read and write sets. Under optimistic concurrency
December 2001
GemStone Systems, Inc.
6-11