geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: SQL transaction deadlock
Date Wed, 31 May 2006 17:57:10 GMT
Zakharov, Vasily M wrote:
> Santosh,
>
> Unfortunately, that didn't help. :(
> Also, commitbeforeautocommit only works for local transactions, and I
> need XA.
>
> Thank you anyway. :)
>
>  Vasily
>
>
> -----Original Message-----
> From: Santosh Koti [mailto:Santosh_Koti@infosys.com] 
> Sent: Friday, May 26, 2006 7:35 AM
> To: user@geronimo.apache.org
> Subject: RE: SQL transaction deadlock
>
>
> Vasily,
>
> I also had faced a similar kind of problem (if not exactly)  , try these
> options :
>
>              1) Increase ur connection pools
>              2) Increase the timeout also
>              3) In ur connection pool deployment set this:
> commitbeforeautocommit=true  & then redeploy ur db
> plan  & test.
>
>
> PS: Not sure, may work , just give a try.
>
>    
>
>
>
> Thanks,
> Santosh.
> "Don't talk about yourself; it will be done when you leave. "
>
>
>
> -----Original Message-----
> From: Zakharov, Vasily M [mailto:vasily.m.zakharov@intel.com]
>
> Sent: Friday, May 26, 2006 4:32 AM
> To: user@geronimo.apache.org
> Subject: SQL transaction deadlock
>
> Hi, all,
>
> Here's another strange transaction rollback I'm having while working
> with Derby through Geronimo.
>
> The question is, if this is an application problem that makes
> inconsistent requests, or it could be a hole in Geronimo/TranQL/Derby
> connector/database?
>
> javax.ejb.TransactionRolledbackLocalException
> 	at
> org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolic
> y.java:123)
>
>   
SNIP
> org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolic
> y.java:119)
> 	at
> org.openejb.transaction.TransactionContextInterceptor.invoke(Transaction
> ContextInterceptor.java:80)
> 	at
> org.openejb.slsb.StatelessInstanceInterceptor.invoke(StatelessInstanceIn
> terceptor.java:98)
> 	at
> org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolic
> y.java:140)
SNIP
> Caused by: javax.ejb.EJBException: Unable to load data for field
> 	at
> org.tranql.ejb.CMPFieldFaultTransform.get(CMPFieldFaultTransform.java:66
> )
> 	at org.tranql.ejb.OneToManyCMR.set(OneToManyCMR.java:77)
> 	at
> org.tranql.ejb.SingleValuedCMRAccessor.set(SingleValuedCMRAccessor.java:
> 66)
SNIP
> org.spec.jappserver.mfg.workorderent.ejb.WorkOrderCmp20EJB.ejbPostCreate
> (WorkOrderCmp20EJB.java:239)
> 	at
> org.spec.jappserver.mfg.workorderent.ejb.WorkOrderCmp20EJB$$FastClassByC
> GLIB$$5801b0f0.invoke(<generated>)
> 	at
> org.openejb.entity.cmp.CMPCreateMethod.execute(CMPCreateMethod.java:213)
>   
SNIP
> org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolic
> y.java:119)
> 	... 38 more
> Caused by: org.tranql.ql.QueryException: Error executing statement:
> SELECT T.WO_NUMBER FROM M_WORKORDER T WHERE T.WO_ASSEMBLY_ID = ?
> 	at
> org.tranql.sql.jdbc.JDBCQueryCommand.execute(JDBCQueryCommand.java:79)
> 	at
> org.tranql.ejb.MultiValuedCMRFaultHandler.fieldFault(MultiValuedCMRFault
> Handler.java:65)
> 	at
> org.tranql.ejb.CMPFieldFaultTransform.get(CMPFieldFaultTransform.java:54
> )
> 	... 52 more
> Caused by: SQL Exception: A lock could not be obtained due to a
> deadlock, cycle of locks and waiters is:
> Lock : ROW, M_WORKORDER, (3,30)
>   Waiting XID : {5683, S} , APP, SELECT T.WO_NUMBER FROM M_WORKORDER T
> WHERE T.WO_ASSEMBLY_ID = ?
>   Granted XID : {5684, X}
>
> Lock : ROW, M_WORKORDER, (3,31)
>   Waiting XID : {5684, S} , APP, SELECT T.WO_NUMBER FROM M_WORKORDER T
> WHERE T.WO_ASSEMBLY_ID = ?
>   Granted XID : {5683, X}
>
> . The selected victim is XID : 5683.
> 	at
> org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> 	at
>   
 ====  SNIP  === 

Hi -

It seems like this may be caused by multiple XA transactions interfering 
with each other.  The two select statements alone would not require 
exclusive locks even at the most restrictive isolation level ( 
TRANSACTION_ SERIALIZABLE ).  They should never deadlock within a single 
statement transaction (e.g. autocommit) which, of course, you say you 
are not using because of XA . 

I'm going to guess that both threads are separate, multiple statement 
transactions that are holding exclusive locks because of a previous data 
modification statement (? CMPCreateMethod ?).  They may need to be 
serialized in some fashion?

I don't know much about Containers and XA but think you should be 
setting them up to use the Derby XA datasource:
        # org.apache.derby.jdbc.EmbeddedXADataSource
                 Derby's implementation of a javax.sql.XADataSource.

HTH



Mime
View raw message