Bugs item #600435, was opened at 2002-08-26 22:27
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=600435&group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Kyle Downey (kdowney)
Assigned to: Bill Burke (patriot1burke)
Summary: deadlock detected erroneously
Initial Comment:
I have a session bean method calling a CMP Entity
method. They are set up as follows in terms of
transactions:
<container-transaction>
<method>
<ejb-name>KeySequence</ejb-name>
<method-
name>getNextKeyAfterIncrementingBy</method-name>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>commonsvc/KeyGenerator</ejb-
name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
The session call successfully creates the Entity EJB,
but the second call (to actually use the newly-created
Entity) from the same client, in what I would assume is
the same transaction, fails with this exception:
Caused by:
org.jboss.ejb.plugins.lock.ApplicationDeadlockException
: Application
deadlock detected: Current thread already has tx lock in
different transaction.
at
org.jboss.ejb.plugins.lock.BeanLockSupport.deadlockDet
ection(BeanLock
Support.java:182)
at
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.w
aitForTx(QueuedP
essimisticEJBLock.java:283)
at
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.d
oSchedule(Queued
PessimisticEJBLock.java:189)
at
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.s
chedule(QueuedPe
ssimisticEJBLock.java:140)
at
org.jboss.ejb.plugins.EntityLockInterceptor.invoke
(EntityLockIntercep
tor.java:103)
at
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke
(EntityCreation
Interceptor.java:69)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInte
rceptor.java:107)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxIntercep
torCMT.java:255)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:6
0)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.
java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:203)
at org.jboss.ejb.EntityContainer.invoke
(EntityContainer.java:493)
at
org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv
oke(BaseLoca
lContainerInvoker.java:301)
at org.jboss.ejb.plugins.local.EntityProxy.invoke
(EntityProxy.java:38)
Note that this is triggered by a single call to the session
EJB from a single client (a unit test), so it should not be
possible to create deadlock.
Database: Postgresql
JVM: JDK 1.3.1_03 (Sun)
JBoss: 3.0.1
--kd
----------------------------------------------------------------------
Comment By: Georg Schmid (giorgio42)
Date: 2002-09-13 10:13
Message:
Logged In: YES
user_id=437570
Bill,
although you are right, this behaviour is a major pain.
The default pessimistic locking reduces CMP-based apps in
JBoss into some kind of single tasking MS-DOS style crap.
6 year ago I had to port some kind of flock/lockf stuff from
SCO Unix to MS-DOS5.0. This would have been simple, if
MS-DOS had the same locking semantics as Unix, because
the MS compiler already provides the functions.
The problem however is: in Unix, if a process locks a region
in a file it has locked already, the locked regions
are "merged" (it probably increments a reference count and
then continues). In MS-DOS this is not done, so a process
can lock itself out of a file region it has locked itself.
Which is ridiculous. I had to build and maintain a list of all
already locked regions and if a region was already locked,
not try to lock it again.
The default pessimistic locking acts like MS-DOS file
locking, where it should behave like the SCO Unix version.
My 2 cents.
Georg
----------------------------------------------------------------------
Comment By: Kyle Downey (kdowney)
Date: 2002-09-12 20:37
Message:
Logged In: YES
user_id=17198
Yes, you are right. I had the declaration backward.
----------------------------------------------------------------------
Comment By: Bill Burke (patriot1burke)
Date: 2002-09-12 19:56
Message:
Logged In: YES
user_id=176497
This bug is invalid. You have accessed the bean in a transaction
then you called a RequiresNew method. So you will have
deadlock.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=600435&group_id=22866
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
