openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <>
Subject [jira] Commented: (OPENJPA-381) OpenJPA is not doing Optimistic locking when running in JEE evnironment
Date Wed, 26 Sep 2007 17:16:50 GMT


Patrick Linskey commented on OPENJPA-381:

The comments in this thread seem to discuss transaction isolation levels, and not optimistic
locking. However, the subject states that OpenJPA is not doing optimistic locking. Maybe we
can change the subject to better reflect the problem described?

Regarding the problem itself: I don't understand what the issue is. OpenJPA lets the container
configure the default isolation level; the JPA spec describes behavior at read-committed.
The JPA spec does not prohibit higher isolation levels, and to the best of my understanding,
the optimistic locking requirements of the spec are obeyed when using repeatable-read. So,
the only issue here is that in a WebSphere environment, the defaults might not allow as much
read-concurrency as is possible with different configurations.

Before going too far down this path, we should ascertain whether or not the WebSphere drivers
even allow changing the isolation level after a JTA-managed transaction has begun.

> 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