[jira] Commented: (OPENJPA-381) OpenJPA is not doing Optimistic locking when running in JEE evnironment

["Sargol Sadeghi (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OPENJPA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992394#comment-12992394 ] 

Sargol Sadeghi commented on OPENJPA-381:
----------------------------------------

Hello 
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"     
             value="jndi(TransactionManagerName=java:appserver/TransactionManager)"/> 


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. 

Regards, 
Sargol 
  

> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira