Summary: Software Atomic Transactions in FLEX
C. Scott Ananian
November 28, 2001
1 Data Structures
Transaction support uses the same "inflated object" extension mechanism which
is used for thread synchronization, clustered heaps, JNI data, and finalization for
certain garbage collectors. The basic object data structure, as shown in figure 1, is
unchanged, although fields containing the specified FLAG VALUE have different
semantics. The flag value is used to indicate that the field value is "not here";
that is, the code must consult the transaction information to find the field's current
value. This happens very rarely even when no transaction is associated with the
object; Shasta  has shown that the overhead entailed by such "false" transactions
is expected to be extremely low.
The "inflated object" data structure, shown in figure 2, has an "object versions"
linked list associated with it. Each entry conceptually stores information about a
different, possibly-uncommitted, version of the object. One of these versions is
guaranteed to be "most recent committed", and it is guaranteed that the "most
recent committed" version will be the first committed version in the list.
The commit record structure is shown in figure 4. The pointer to the commit