You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Sargol <s_...@hotmail.com> on 2011/02/07 15:32:14 UTC

Re: EntityManager dosn't release connection in XA transactions

Hello 
We have encountered a problem that seems it is related to this type of
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 
  
-- 
View this message in context: http://openjpa.208410.n2.nabble.com/EntityManager-dosn-t-release-connection-in-XA-transactions-tp4205041p6000447.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Re: EntityManager dosn't release connection in XA transactions

Posted by Sargol <s_...@hotmail.com>.
Hi,
For your information, we got the "ORA-02049: timeout: distributed
transaction waiting for lock" error when the .net side of application had
not been 
involved in the transaction. Does it show that the problem is not related to
the distributed transaction configurations? Is there any special property
that we 
must have configured regarding Openjpa locking. 

Thank you in advance.

Regards,
Sargol  
-- 
View this message in context: http://openjpa.208410.n2.nabble.com/EntityManager-dosn-t-release-connection-in-XA-transactions-tp4205041p6018217.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Re: EntityManager dosn't release connection in XA transactions

Posted by Sargol <s_...@hotmail.com>.
Hi Milosz,

Thank you for your attention.

This timeout exception occurs only from time to time.
For your information, We have configured a distributed transaction in our
application server in order to support transaction between Java and .NET
clients.
WS-AT is the protocol which has been used for managing atomic transactions
between distributed applications.
Also Oracle DataSource Classname and XADataSource as the resource type are
the
connection pool configurations in Glassfish.

Please let me know if you have any suggestions.
Thank you once again.

Regards,
Sargol

-- 
View this message in context: http://openjpa.208410.n2.nabble.com/EntityManager-dosn-t-release-connection-in-XA-transactions-tp4205041p6009254.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Re: EntityManager dosn't release connection in XA transactions

Posted by Miłosz <mt...@o2.pl>.
Hi Sargol,

Is the timeout exception occuring every time while executing UPDATE statement or only sometimes?

If it is permanent, maybe you have not configured the XA transaction coordinator properly. In this case I would ask on a GlassFish forum.

If it happens only from time to time, your application might be causing deadlocks. One common deadlock scenario is when you have two tables and two threads are updating them but each thread updates them in a different order.

What is (are) the other resource which participates in your XA transaction? Maybe the other resource performs slowly or even blocks causing the XA transaction timing out.

Cheers,
Milosz

> Hi Milosz , 
> 
> Thank you for your reply. 
> The sql log statements are enabled and I don't have any SELECT FOR UPDATE
> statements
> and there is an UPDATE statement so I can make sure that openjpa does not
> use pessimistic transaction.
> 
> So, how can I find that for what reason the transaction has not been
> commited and why this exception has been raised.
> 
> 
> Here is the stack trace. It would be grateful if you could help me. 
>    
> 
> Regards, 
> Sargol
> 
> >>>>>>>> Stack trace <<<<<<<<<<<<
> 
>  <openjpa-1.2.1-r752877:753278 nonfatal general error>
> org.apache.openjpa.persistence.PersistenceException: ORA-02049: timeout:
> distributed transaction waiting for lock
>  {prepstmnt 1631220936 UPDATE GC1ACCOUNT SET G1004BAL = ?, G1004VER = ?,
> TRCVER = ? WHERE G1004ID = ? AND TRCVER = ? [params=(double) 1902345.0,
> (double) 1296.0, (int) 1297, (long) 65996, (int) 1296]} [code=2049,
> state=42000]
> FailedObject:
> com.kishware.core.gl.data.Account-com.kishware.core.gl.data.Account-65996
> 	at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232)
> 	at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197)
> 	at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
> 	at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:72)
> 	at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:131)
> 	at
> org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:82)
> 	at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
> 	at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
> 	at
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:543)
> 	at
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
> 	at
> org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
> 	at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
> 	at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
> 	at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717)
> 	at
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> 	... 152 more
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: ORA-02049:
> timeout: distributed transaction waiting for lock
>  {prepstmnt 1631220936 UPDATE GC1ACCOUNT SET G1004BAL = ?, G1004VER = ?,
> TRCVER = ? WHERE G1004ID = ? AND TRCVER = ? [params=(double) 1902345.0,
> (double) 1296.0, (int) 1297, (long) 65996, (int) 1296]} [code=2049,
> state=42000]
> 	at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:192)
> 	at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:57)
> 	at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:866)
> 	at
> org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
> 	at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586)
> 	at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
> 	at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
> 	... 162 more


Re: EntityManager dosn't release connection in XA transactions

Posted by Sargol <s_...@hotmail.com>.
Hi Milosz , 

Thank you for your reply. 
The sql log statements are enabled and I don't have any SELECT FOR UPDATE
statements
and there is an UPDATE statement so I can make sure that openjpa does not
use pessimistic transaction.

So, how can I find that for what reason the transaction has not been
commited and why this exception has been raised.


Here is the stack trace. It would be grateful if you could help me. 
   

Regards, 
Sargol

>>>>>>>> Stack trace <<<<<<<<<<<<

 <openjpa-1.2.1-r752877:753278 nonfatal general error>
org.apache.openjpa.persistence.PersistenceException: ORA-02049: timeout:
distributed transaction waiting for lock
 {prepstmnt 1631220936 UPDATE GC1ACCOUNT SET G1004BAL = ?, G1004VER = ?,
TRCVER = ? WHERE G1004ID = ? AND TRCVER = ? [params=(double) 1902345.0,
(double) 1296.0, (int) 1297, (long) 65996, (int) 1296]} [code=2049,
state=42000]
FailedObject:
com.kishware.core.gl.data.Account-com.kishware.core.gl.data.Account-65996
	at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232)
	at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197)
	at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
	at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:72)
	at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:131)
	at
org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:82)
	at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
	at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
	at
org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:543)
	at
org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:106)
	at
org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
	at
org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
	at
org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
	at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717)
	at
org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
	... 152 more
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: ORA-02049:
timeout: distributed transaction waiting for lock
 {prepstmnt 1631220936 UPDATE GC1ACCOUNT SET G1004BAL = ?, G1004VER = ?,
TRCVER = ? WHERE G1004ID = ? AND TRCVER = ? [params=(double) 1902345.0,
(double) 1296.0, (int) 1297, (long) 65996, (int) 1296]} [code=2049,
state=42000]
	at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:192)
	at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:57)
	at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:866)
	at
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
	at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586)
	at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
	at
org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
	... 162 more
|#]
-- 
View this message in context: http://openjpa.208410.n2.nabble.com/EntityManager-dosn-t-release-connection-in-XA-transactions-tp4205041p6003588.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: EntityManager dosn't release connection in XA transactions

Posted by Miłosz Tylenda <mt...@o2.pl>.
Hi Sargol,

Your properties (the first three mentioned) look sane. Did you enable SQL statement logging either in OpenJPA[1] or database? If OpenJPA used pessimistic transactions, you would see SELECT FOR UPDATE statements in the log. Are there any? It might be that the timeout problem is not caused by OpenJPA. For example, the XA transactions might not get committed for some reason.

Regards,
Milosz


[1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_logging_channels

> 
> Hello 
> We have encountered a problem that seems it is related to this type of
> 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 
>   
>