Bugs item #600435, was opened at 2002-08-26 15: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: Bill Burke (patriot1burke)
Date: 2002-09-13 04:42
Message:
Logged In: YES
user_id=176497
True Georg, but if you want a cache, you have to have
pessimistic locking. Currently there is no requirement for an
Entity Bean to be serializable so we can't implement cache-copy-
versioned cache.
You can alleviate locking pains by
1. Declaring read only beans <read-only> in jboss.xml
2. Declare read-only metods. (Won't become locked if only read
methods are called.)
3. Use Commit 'B' with Instance Per Transaction container
configuration. (No transactional locking!) Also, this is Weblogic's
exact default behavior.
Please refer to new 3.0 docs.
----------------------------------------------------------------------
Comment By: Georg Schmid (giorgio42)
Date: 2002-09-13 03: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 13: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 12: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
