Chapter 9. Transaction

9.1. Transaction Types
9.2. The JDO Transaction Interface
9.2.1. Transaction Properties
9.2.2. Transaction Demarcation




    from.decrementAccount (amnt);
    to.incrementAccount (amnt);

Now suppose that user Alice wants to transfer 100 dollars to user Bob. No problem: you invoke your transferFunds method, supplying Alice in the from parameter, Bob in the to parameter, and 100.00 as the amnt. The first line of the method is executed, and 100 dollars is subtracted from Alice's account. But then, something goes wrong. An unexpected exception occurs, or the network fails, and your method never completes.


The importance of transactions should now be clear. If the two lines of the transferFunds method had been placed together in a transaction, it would be impossible for only the first line to succeed - either the funds would be transferred properly or they would not be transferred at all and an exception would be thrown. Money could never vanish into thin air, and the data store could never get into an inconsistent state.

9.1. Transaction Types



JDO does not have pessimistic transactions per se. Instead, JDO has datastore transactions. This is JDO's way of admitting that some datastores do not support pessimistic semantics, and that the exact meaning of a non-optimistic JDO transaction is dependent on the datastore. In most JDO implementations, a datastore transaction is equivalent to a pessimistic transaction.




Kodo supports both optimistic and datastore transactions. Kodo defaults JDO datastore transactions to pessimistic semantics; however, Kodo also offers advanced locking and versioning APIs for fine-grained control over database resource allocation and object versioning. See Section 9.4, “Object Locking” and Section 5.8, “Lock Groups” of the Reference Guide for details on locking. Section 15.10, “Version” of this document covers object versioning strategies.


Skip navigation bar   Back to Top