Transactions
Transactions
Changes to virtual objects are committed or rolled back together in transactions defined in the application. VOSS transactions have full ACID properties (Atomic, Consistent, Isolated and Durable) and may be open-ended in time, to include all objects which are sent messages by that process until explicitly committed or rolled back, or alternatively they may created by evaluating a block of code for commit or rollback (read-write or read-only evaluation of the block). Either kind of transaction may be committed and its locks released, or committed with locks retained for further work, and block transactions are automatically retried after rollback on lock time-out or at the user’s option in interactive mode. Detection of changes to virtual objects is fully automatic.
Transactions may be nested to any depth in a tree-structure of sub-transactions and siblings as the application may require. Each transaction tree is the property of its parent VOSession, which is the anchor for a default open-ended transaction called Top, automatically created, with a new parent VOSession, by any process the first time it sends a message to a virtual object. Other processes in the image are not affected.
A VOSession, with its tree of transactions containing locked objects, may be connected to, at most, one process, or none, in which state is is said to be parked, accessible only via its timestamp ID number in the global LocalVOSSServer; in this state it is like a train in a siding, waiting for a locomotive process to connect to it. Any process may connect to a parked VOSession, provided that process is not already connected to another VOSession. If a Top transaction is committed or rolled back a new one replaces it automatically, however Top is not normally used in applications, it is mainly a debugging aid to catch virtual objects which have been erroneously sent messages without (i.e. outside of) a transaction. A committing transaction also timestamps all the objects which it changes; this timestamp is available for use by applications, it is also used in the versioning transaction feature and in (automatic) refreshing of the caches.
The essence of a transaction is that all the changes are committed or none of them is, and two-phase commit assures the integrity of this operation in the event of application software errors or process termination by the program or by the user, even if the transaction has been partially written to disk at the time, or in the event that one of several distributed virtual spaces involved in the transaction is unable to commit. All transactions have this feature and no user or programmer intervention is required.
