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