Java Persistent Objects - Transaction Type

Transaction Type

A Transaction forms a unit of work. The Transaction manages what happens within that unit of work, and when an error occurs the Transaction can roll back any changes performed. There are two basic types of transaction. Transactions can lock all records in a datastore and keep them locked until they are ready to commit their changes. These are known as Pessimistic (or datastore) Transactions. On the other hand, transactions can simply assume that things in the datastore will not change until they are ready to commit, not lock any records and then just before committing make a check for changes. These are known as Optimistic Transactions. These are both described below.

See also :-

Datastore Connections

Pessimistic (Datastore) Transactions

Pessimistic transactions are the default in JDO. They are suitable for short lived operations where no user interaction is taking place and so it is possible to block access to datastore entities for the duration of the transaction.

By default JPOX does not currently lock the objects in use in a pessimistic transaction, but you can configure this behaviour by setting the PersistenceManagerFactory property org.jpox.useUpdateLock to true. This will result in all "SELECT ... FROM ..." statements being changed to be "SELECT ... FROM ... FOR UPDATE". This will be applied only where the underlying RDBMS supports the "FOR UPDATE" syntax. This property has no effect on Optimistic transactions since no locking is needed there (by definition).

JPOX also allows specification of the transaction isolation level. This is specified via the PersistenceManagerFactory property org.jpox.transactionIsolation. It accepts the standard JDBC values of READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE. The default is READ_COMMITTED. If the RDBMS doesn't support a particular isolation level then it will silently be changed to one that is supported.

With a pessimistic transaction JPOX will grab a datastore connection at the first operation, and maintain it for the duration of the transaction. A single connection is used for the transaction (with the exception of any Identity Generation operations which need datastore access, since these can use their own connection).

Optimistic Transactions

Optimistic transactions are the other option in JDO. They are suitable for longer lived operations maybe where user interaction is taking place and where it would be undesirable to block access to datastore entities for the duration of the transaction. The assumption is that data altered in this transaction will not be updated by other transactions during the duration of this transaction. The data is checked just before commit to ensure the integrity in this respect. The most convenient way of checking data for updates is to maintain a column on each table that handles optimistic transaction data. The user will decide this when generating their MetaData.

Rather than placing version/timestamp columns on all user datastore tables, JDO2 allows the user to notate particular classes as requiring optimistic treatment. This is performed by adding a version element to the Meta-Data for the classes concerned, for example

<version strategy="version-number" column="version"/>

The "column" part is optional and allows the user to define the name of the column to use for the optimistic column. The "strategy" tells JPOX to allow optimistic transaction capability on this class and to use "timestamp" as the means of checking for updates.

JPOX supports 3 optimistic locking strategies.

version-number will generate an integer-based column to store the version, and the version will start at 0, being incremented by each update.
date-time will generate a Timestamp-based column and store the timestamp of the last update. Please be aware that some RDBMS dont store the milliseconds in timestamp columns and so this strategy can be next to useless - we recommend using the "version-number" strategy above unless you know that your RDBMS handles timestamp columns correctly.
none will generate an integer-based column to store the version, BUT no checking will be made at runtime on validity of the updates. This is useful as a way of having your obejcts versioned and still use them with pessimistic transactions.

JDO provides a method for accessing the version of an object. You can call JDOHelper.getVersion(object) and this returns the version as an Object (typically Long or Timestamp). This will return null for a transient object, and will return the version for a persistent object. If the object is not PersistenceCapable then it will also return null.

In JPOX 1.1, operations on collections/maps are not delayed until commit hence such operations cannot be relied on in a pure optimistic transaction scenario. This is implemented in JPOX 1.2.