help: transaction timedout (deadlock) with cmp
Haoguang
I have a stateless session bean and a entity bean with cmp cmt implementation.
We use 3 methods from the session bean, let's say 'a', 'b' and 'c'. a calls b
recursively and b calls c once. a and b have the <Required> trans-attrib. c has
<Supports> as its trans-attrib. a doesn't do much except it calls b multiple times.
b calls c first, then calls finderMethod on the entitybean, then calls create
on the entitybean. And c calls another finderMethod on the entitybean.
It works fine if only b is called remotely. But if we call a, we get a weblogic.transaction.internal.TimedOutException.
It seems after the first call to b (after the create on the entity bean, the transaction
is not committed yet), the finder in c when b is called for the 2nd time encounter
a deadlock with the previous processing (the create for sure).
We are using Weblogic 7 sp1 with Sybase.
Your help or comments will be appreciated.
Slava Imeshev
You say that A calls B repeatedly. Have you tried measuring
processing time for a single B call? What is the JTA timeout
for your server? Could you also post the stack trace here?
Regards,
Slava Imeshev
"Haoguang" <haog...@az.vub.ac.be> wrote in message
news:3e28...@newsgroups.bea.com...
Haoguang
Hi,
The B call time can be ignored. The timedout is not caused by the long B processing
time. I have tried different settings for the JTA timeout range from 5min to 30sec.
And by the dba I could clearly see that different connections were started by
the wls and the the selection statement is effective waiting for the 1st transaction.
I don't know if the server exception stack trace can be helpful. But here it is:
Start server side stack trace:
java.rmi.RemoteException: Transaction Rolledback.; nested exception is:
weblogic.transaction.internal.TimedOutException: Transaction timed out after
33 seconds
12:a6c6f0e47f28edb9
weblogic.transaction.internal.TimedOutException: Transaction timed out after 33
seconds
12:a6c6f0e47f28edb9
at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1198)
at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:888)
at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1695)
at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:813)
at weblogic.transaction.internal.TransactionManagerImpl$1.run(TransactionManagerImpl.java:1661)
at java.lang.Thread.run(Thread.java:479)
End server side stack trace
Thanks for the response,
Haoguang
Slava Imeshev
From stack trace it just follows that TX lasts longer
that allowed 30 seconds. Normally it's fixed by increasing
TX timeout. Do you see exactly the same exception
when you increase timeout?
Could also you try posting a code snippet showing the
sequence of calls?
Regards,
Slava Imeshev
"Haoguang" <haog...@az.vub.ac.be> wrote in message
news:3e2b...@newsgroups.bea.com...
Haoguang
Hi, Slava,
Yes, the TX takes indeed longer than 30sec because it is an uncommited tx and
waits for till just before the method (A) return. And yes, I got the same exception
stack trace if I set the TX timeout to, let's say 5 min.
The problem is that the container starts another transaction with a new db connection
when the finder in B is called (by A) for the second time. It's really a deadlock
situation, not a method time problem.
Thanks,
Slava Imeshev
I think something is wrong here. Let me ask you some questions.
o How do you set transaction timeout?
o What are values of <trans-attribute> for the participating beans?
o How do you know that the server start new transaction?
o What is the stacktrace for TX timeout 5 minutes?
Regards,
Slava Imeshev
"Haoguang" <haog...@az.vub.ac.be> wrote in message
news:3e2d0a1c$1...@newsgroups.bea.com...