openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sargol Sadeghi (JIRA)" <>
Subject [jira] Commented: (OPENJPA-381) OpenJPA is not doing Optimistic locking when running in JEE evnironment
Date Wed, 09 Feb 2011 08:59:57 GMT


Sargol Sadeghi commented on OPENJPA-381:

We have encountered the same problem that seems it is related to the openjpa settings. 
We have configured a distributed transaction in our application server and 
we are using openjpa 1.2.1 and Glassfish application server. Although the default behavior
of transaction locking must be optimistic, 
it seems that pessimistic locking has been happened. 
It is found that Row Lock contention happens in a specific table. 
This is the exception : 
java.sql.SQLException: ORA-02049: timeout: distributed transaction waiting for lock 
Is there any property which has to be set related to the XA transactions management for openjpa?

For your information, already all the following properties have been set. 

1. <persistence-unit name="JPXA" transation-type="JTA"> 

2. <property name="openjpa.TransactionMode" value="managed"/> 

   You can try a plug-in string to lookup the TM in JNDI (the value is the JNDI name of GlassFish
TM as per Google search) 
3. <property name="openjpa.ManagedRuntime"     

Following searching about this locking problem, we found that we should add two more properties
for openjpa as listed below. 

<property name="openjpa.LockManager" value="version" /> 
<property name="openjpa.jdbc.TransactionIsolation" value="read-committed" /> 

but this time we have got another error: org.apache.openjpa.persistence.PersistenceException:
ORA-02089: COMMIT is not allowed in a subordinate session. 

Thanks for any help. 


> 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.
For more information on JIRA, see:


View raw message