14.1 Advanced Transaction Semantics

The JDO specification currently defines semantics for datastore transactions and optimistic transactions. For the majority of applications, these transactional semantics should prove sufficient; however, some applications may need more advanced or specialized capabilities or need to take advantage of features offered by the underlying datastore that they are using.

To this end, JDO 2.0 may add additional transaction semantics, principally nested transactions, savepoints, and explicit locking.

14.1.1 Nested transactions

With the current JDO specification, there can be only a single active transaction per PersistenceManager instance. All work done within the transaction is either committed or rolled back as a whole.

Nested transactions define the ability to begin a transaction within the scope of another transaction (often referred to as the parent transaction). Each nested transaction can be begun and committed or rolled back as per a normal transaction. However, even though committed, a nested transaction may still be subject to rollback by its parent transaction. And a parent transaction cannot be completed until all its nested transactions have completed.

Nested transactions are a way of breaking down a single "unit of work" into multiple subtasks that can be distributed and then committed or rolled back independent of each other, but still within the scope of the bigger unit of work. Supporting nested transactions within JDO will require a clear definition of the concurrency control and means of data sharing between nested transactions.

14.1.2 Savepoints

Savepoints provide a means to rollback only a portion of a transaction. In many ways, they are like a single nested transaction.

Using savepoints, an application can begin a transaction and at some point create a savepoint. At a later point, the application can decide to undo the savepoint. This essentially rolls back the transaction to the point at which the savepoint was created, undoing all the changes that were made thereafter, without having to rollback the entire transaction.

Savepoints are a useful undo mechanism for applications in which a transaction consists of a sequence of tasks . Should a given task fail, rather than having to rollback the entire transaction and redo everything, a savepoint can be used. The savepoint restores the state of any persistent objects to the beginning of the failed task, so it can be retried without affecting the other tasks that have already been successfully completed.

14.1.3 Explicit locking

The current JDO specification does not define APIs to allow an application to explicitly request a particular lock on a given persistent object. Instead, locks are implicitly managed by the JDO implementation in conjunction with the underlying datastore to ensure that concurrency control is enforced between different transactions.

Some applications may need to be able to explicitly request shared or exclusive locks on particular persistent objects. These locks can be used for synchronization of multiple, distributed applications all using the same datastore.