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).