Java Reference
In-Depth Information
Although this sounds straightforward, there are several issues with JDO data-
store transactions. First, JDO datastore transactions potentially lock every row that
is retrieved from a set of tables, which can sometimes impact the performance
and increase the probability of deadlocks. It can also be unnecessary because
many applications only need to lock rows in specific tables. Fortunately, some JDO
implementations let the application control which objects are locked. For exam-
ple, you can configure Versant Open Access JDO to only lock the first object
loaded during a transaction, which is sufficient for some transactions.
Second, in order to lock the rows in the database, the JDO implementation
(and Hibernate for that matter) must ignore the process-level cache and access
the database. In some applications this can reduce performance significantly.
The third issue to consider is that the JDO implementation can translate a
JDOQL query into a SQL statement that uses constructs that are incompatible with
a FOR UPDATE clause. If this happens, you will need to change the query or use a dif-
ferent concurrency mechanism.
Optimistic and pessimistic locking are two of the concurrency mechanisms
that a JDO application can use. Isolated database transactions are the third mech-
anism. Let's explore how to configure the transaction isolation level.
Using serializable or repeatable read transactions
Some JDO implementations provide extensions to the JDO specification for con-
trolling the isolation level of datastore transactions. Examples of the different
ways of specifying the transaction isolation level include:
Setting a PersistenceManagerFactory property
Configuring the isolation level of the DataSource that is used by the Persis-
tenceManagerFactory , as was shown in section 12.2.4
Using the TransactionInterceptor to specify the isolation level, as was
shown in section 12.2.4
Unfortunately, these extensions are specific to the JDO implementation used by
your application. You can check your implementation's documentation for more
information.
Signaling concurrent update failures
A JDO implementation signals errors by throwing an exception that is an instance
of one of the subclasses of JDOException . JDOException , which is a subclass of
RuntimeException , has many subclasses, including those shown in figure 12.7.
 
 
 
Search WWH ::




Custom Search