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 process and there is always a default transaction called Top under any process which has ever sent a message to a virtual object. Other processes in the image are not affected. If a Top transaction is committed or rolled back a new one replaces it automatically. 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 refreshing 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.
