openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Lee (JIRA)" <>
Subject [jira] Commented: (OPENJPA-381) OpenJPA is not doing Optimistic locking when running in JEE evnironment
Date Tue, 25 Sep 2007 00:50:50 GMT


Daniel Lee commented on OPENJPA-381:

The following information was found "out of sync" between OpenJPA manual and JPA standard.
 If the default
transaction isolation level is set to "default", OpenJPA passes the control to container to
use whatever container's
default.  In that case, there is no guarantee of read-committed transaction isolation nor
optimistic locking.
OpenJPA user's guide need to be updated too.

In "Sun Microsystems JSR 220: Enterprise JavaBeansTM,Version 3.0 Java Persistence API" Section
3.4 Optimistic Locking and Concurrency
This specification assumes the use of "optimistic locking". It assumes that the databases
to which persistence
units are mapped will be accessed by implementations using read-committed isolation (or a
vendor equivalent in which long-term read locks are not held), and that writes to the database
occur only when the flush method has been invoked—whether explicitly by the application,
or by the
persistence provider runtime in accordance with the flush mode setting. If a transaction is
active, a compliant
implementation of this specification is permitted to write to the database immediately (i.e.,
a managed entity is updated, created, and/or removed), however, the configuration of an
implementation to require such non-deferred database writes is outside the scope of this specification.
The configuration of the setting of optimistic lock modes is described in section 3.4.3. Applications
prefer the use of pessimistic locking may require that database isolation levels higher than
be in effect. The configuration of the setting of such database isolation levels, however,
is outside the
scope of this specification.

and in "Apache OpenJPA User's Guide" Section 2.6.17:
2.6.17. openjpa.jdbc.TransactionIsolation
Property name: openjpa.jdbc.TransactionIsolation
Configuration API: org.apache.openjpa.jdbc.conf.JDBCConfiguration.getTransactionIsolation
Resource adaptor config-property: TransactionIsolation
Default: default
Possible values: default, none, read-committed, read-uncommitted, repeatable-read, serializable
Description: The JDBC transaction isolation level to use. See Section 4.5, " Setting the Transaction
Isolation " [198f]or details.

> OpenJPA is not doing Optimistic locking when running in JEE evnironment
> -----------------------------------------------------------------------
>                 Key: OPENJPA-381
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 1.0.0
>         Environment: JEE
>            Reporter: Daniel Lee
>             Fix For: 1.1.0
> The follwoing code seems to be leaving isolation level to -1 (default) instead of setting
a correct isolation level for the connections.  I think this is not right because this is
leaving the contianer to use its own default isolation level.  It will be, for example, Repeatable-read
when using IBM WebShpere.
> in
>     public static DecoratingDataSource installDBDictionary(DBDictionary dict,
>         DecoratingDataSource ds, final JDBCConfiguration conf,
>         boolean factory2) {
>             ...
>             ccd.setTransactionIsolation(conf.getTransactionIsolationConstant());
>             ...
>     }
> with the default value set in
>     public JDBCConfigurationImpl(boolean derivations, boolean loadGlobals) {
>         super(false, false);
>         String[] aliases;
>         schema = addString("jdbc.Schema");
>         schemas = addStringList("jdbc.Schemas");
>         transactionIsolation = addInt("jdbc.TransactionIsolation");
>         aliases = new String[]{
>             "default", String.valueOf(-1),
>             "none", String.valueOf(Connection.TRANSACTION_NONE),
>             "read-committed", String.valueOf
>             (Connection.TRANSACTION_READ_COMMITTED),
>             "read-uncommitted", String.valueOf
>             (Connection.TRANSACTION_READ_UNCOMMITTED),
>             "repeatable-read", String.valueOf
>             (Connection.TRANSACTION_REPEATABLE_READ),
>             "serializable", String.valueOf(Connection.TRANSACTION_SERIALIZABLE)
>         };
>         transactionIsolation.setAliases(aliases);
>         transactionIsolation.setDefault(aliases[0]);
>         transactionIsolation.set(-1);
>         transactionIsolation.setAliasListComprehensive(true);
>         ...
>     }
> The fix of this is to set it to "Read-Committed" which will make it in sync with JDBC
direct connections.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message