next up previous
Next: Our Product and Up: Some Background and Previous: The EposDB

Transaction Model

 

The EPOSDB supports nested long transactions which form an envelope around a unit of work, and may survive application sessions. Transactions have separate storage areas for changed objects, and we can distinguish between objects in different transactions. Objects are checked out from the parent transaction and can be accessed through the database interface. The objects that contain files are further checked out into an accessible format in the connected workspace, where they can be updated and checked back into the transaction. Objects may be individually checked in from a transaction to its parent before the transactions terminates.
Transactions are explicitly terminated with either a commit or an abort operation, whereupon changed objects are checked in or discarded respectively.
We have extended the transaction model to allow fine-grained control over propagation of changes between parent and child transaction, and between sibling transactions. Objects can be individually checked out or in from the parent transaction, and they can be transferred or copied into the local storage areas of sibling transactions.
It is also possible to access objects residing in an ancestor transaction, but these objects may be changed by other transactions. To provide concurrency control, the transaction model defines a set of flexible lock modes and even allows several transactions to concurrently update an object (requiring merging of the changes).



Passani Luca
Mon Feb 20 21:59:27 MET 1995