openjpa-dev mailing list archives

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


Kevin Sutter commented on OPENJPA-381:

The referenced code in JDBCConfigurationImpl does not set the transaction isolation level.
 It is only setting up the field to house the transaction isolation level.  This IntValue
(transactionIsolation) will contain the extent (or parameters) of the transaction isolation
level setting.  The code block is setting the available values (aliases), the default value
(-1), and whether the list is complete or not.  So, I agree with Patrick that the blocks of
code referenced do not constitute a problem.

Now, there still may be a problem with setting of proper isolation levels, but so far this
Issue doesn't describe it.  And, it may be limited to WebSphere (as Patrick has hinted at).

Concerning Patrick's last question:
>  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.

Correct.  WebSphere doesn't allow the changing of the isolation levels after a JTA transaction
has started.  At least for shareable connections, I know this is true.  For unshareable connections,
this rule may be relaxed a bit.  But, since we deal with shareable connections by default,
that is definitely the most common scenario.  So, as long as we are attempting to change the
isolation levels between transactions, then we should be okay.

> 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