[
https://issues.apache.org/jira/browse/OPENJPA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530491
]
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: https://issues.apache.org/jira/browse/OPENJPA-381
> 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 DataSourceFactory.java:
> public static DecoratingDataSource installDBDictionary(DBDictionary dict,
> DecoratingDataSource ds, final JDBCConfiguration conf,
> boolean factory2) {
> ...
>
> ccd.setTransactionIsolation(conf.getTransactionIsolationConstant());
> ...
> }
> with the default value set in JDBCConfigurationImpl.java:
> 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.
