Hi Jon,

In standard configuration
you get this:

Start transaction (t1)
   a = findBeanInstance(p);
   {jboss locks a to t1}
   a.getValue();
   Start transaction (t2)
      {jboss trys to lock a to t2 - deadlock}
       a.setValue(newValue);
   End transaction
End transaction
{jboss unlocks a from t1}

t2 is not nested within t1, jboss supsends t1
before starting t2, a more accurate diagram would be

Start transaction (t1)
   a = findBeanInstance(p);
   a.getValue();
Suspend Transaction (t1)
Start transaction (t2)
   a.setValue(newValue);
End transaction (t2)
Resume Transaction (t1)
End transaction (t1)

if however you specify getValue()
as a read-only method you get this

Start transaction (t1)
   a = findBeanInstance(p);
   {jboss locks a to t1}
   a.getValue();
   {jboss unlocks a - only read operations}
   Start transaction (t2)
      {jboss locks a to t2}
       a.setValue(newValue);
      {jboss done NOT unlock, setValue is a write operation}
   End transaction
  {jboss unlocks a from t2}
End transaction

Alternatives include:

Instance per transaction (each transaction gets their own
copy of the entity bean with no locking)

Optimistic locking, available in 3.2

Regards,
Adrian

From: Jon Haugsand <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
Subject: [JBoss-user] Transaction differences in weblogic and jboss
Date: 27 Mar 2003 14:23:55 +0100

I think I have discovered a difference between jboss and weblogic
concerning transactions and this is (currently) a bit troublesome for
us.  Given the following metacode:

Start transaction
   a = findBeanInstance(p);
   a.getValue();
   Start transaction
       a.setValue(newValue);
   End transaction
End transaction

This is problem free in weblogic, but jboss errs with deadlock
detection.  Face value, I think JBoss is "correct" because the
container does not know whether you are going to update the value
after the nested transaction.

But can anyone comment on this?  E.g. is it possible to tune this
behaviour in JBoss?

(In the long term we have to rewrite our code so that we avoid such
constructions all together.)

--
 Jon Haugsand, [EMAIL PROTECTED]
 http://www.norges-bank.no



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


_________________________________________________________________
Surf together with new Shared Browsing http://join.msn.com/?page=features/browse&pgmarket=en-gb&XAPID=74&DI=1059




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to