RE: [JBoss-user] Erroneous deadlock detected???
The behaviour imposed by the pessimistic locking violates the principle
of "least surprise" for most Jboss users, I guess. That's the reason why
you have to answer these questions a million times.
If I am using all the EJB/J2EE/CMP stuff, I expect that I do not have to
care about concurrency, transactions and so on. That's the application
server's business.
So when I get deadlock exceptions the first time two users hit the same
web page concurrently, both accessing the same (bad luck!) entity beans
read-only, I am taken aback. Especially if I'm doing only basic stuff
and nothing fancy.
Regards
Georg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Bill Burke
Sent: Tuesday, October 29, 2002 07:16
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] Erroneous deadlock detected???
Queued pessmistic is useful for caching. Without it you can't cache.
You're wrong that it turns jBoss into single tasking. It really depends
on your application and there are other settings you can use. Buy the
for-pay docs(or search the archives, I've answered these questions a
million times before). It goes into details about locking policies.
Ok, so why did he get deadlock detected?
begin tx1
- create entity > this locks it into tx1
- entity.setX ---> tx1 suspended tx2 starts, deadlock, tx1 has lock.
Besides, you can't do a requiresnew call anyways because the newly
created entity will never have been committed! Learn what transaction
isolation is.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Georg
> Schmid
> Sent: Friday, October 25, 2002 6:14 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-user] Erroneous deadlock detected???
>
>
>
> I ran into this same problem a while ago, and I suggested the same (at
> least the thread, that holds the lock, should not be locked out).
> Somebody wrote a 'SimpleReadWriteEJBLock' class, that seems to achieve
> exactly this, but I could not find any info related to it.
>
> You can also try to play around with the method attribute read-only
> setting in jboss.xml (see the DTD). To get better concurrency you may
> consider switching to the Instance Per Transaction configuration (see
> standardjboss.xml) .
>
> The QueuedPessimisticEJBLock does not make any sense with CMP, IMHO
> (if you use it, it turns JBoss into a single tasking system).
>
>
> Georg
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Jim
> Crossley
> Sent: Thursday, October 24, 2002 22:06
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-user] Erroneous deadlock detected???
>
>
> Well, it would seem to me that a ThreadLocal instance could help solve
> this problem. If one thread tries to acquire a lock it already owns,
> it ought to get it, right?
>
> If we were to apply the same semantics you describe to a simple Java
> class, then calling setX would always block...
>
> class C
> {
> synchronized void setX() {
> setY();
> }
> synchronized void setY() {
> ;
> }
> }
>
> If this is really the way JBoss works, and nobody knows a good reason
> why it should, can someone point me to the package/class responsible
> for this behavior and I'll take a whack at fixing it?
>
> Thanks,
> Jim
>
> On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
> > Explanation attempt inline.
> >
> > Regards,
> > Michael Bartmann
> >
> > Jim Crossley wrote:
> > > I have an MDB with the following pseudocode in its onMessage
> > > method:
> > >
> > > public void onMessage(Message msg)
> > > {
> > > // Entity bean = home.create(...)
> > > // bean.setX(...)
> > this starts a tx1 and locks the instance bean.
> > > // bean.setY(...)
> > this suspends the tx1 on bean temporarily,
> > and starts a tx2, which tries to obtain the lock on the bean, which
> > it
>
> > will never get, because tx1 is not commited or rollbacked yet. We
> > had this problem under 2.4.4 w/o deadlock detection. Problem: even
> > the tx timeout didn't work in this case; the server locked
> forever... :-(
> > > }
> > >
> > > Each of the three methods, create, setX, and setY have a
> > > trans-attribute of "RequiresNew". With only one client posting a
> > > message, a "deadlock detected" exception is thrown when setX is
> > > invoked. How can deadlock occur when only one thread is active
> > >
> > > Thanks,
>
RE: [JBoss-user] Erroneous deadlock detected???
Queued pessmistic is useful for caching. Without it you can't cache.
You're wrong that it turns jBoss into single tasking. It really depends on
your application and there are other settings you can use. Buy the for-pay
docs(or search the archives, I've answered these questions a million times
before). It goes into details about locking policies.
Ok, so why did he get deadlock detected?
begin tx1
- create entity > this locks it into tx1
- entity.setX ---> tx1 suspended tx2 starts, deadlock, tx1 has lock.
Besides, you can't do a requiresnew call anyways because the newly created
entity will never have been committed! Learn what transaction isolation is.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Georg Schmid
> Sent: Friday, October 25, 2002 6:14 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-user] Erroneous deadlock detected???
>
>
>
> I ran into this same problem a while ago, and I suggested the same (at
> least the thread, that holds the lock, should not be locked out).
> Somebody wrote a 'SimpleReadWriteEJBLock' class, that seems to achieve
> exactly this, but I could not find any info related to it.
>
> You can also try to play around with the method attribute read-only
> setting in jboss.xml (see the DTD).
> To get better concurrency you may consider switching to the Instance Per
> Transaction configuration (see standardjboss.xml) .
>
> The QueuedPessimisticEJBLock does not make any sense with CMP, IMHO (if
> you use it, it turns JBoss into a single tasking system).
>
>
> Georg
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Jim
> Crossley
> Sent: Thursday, October 24, 2002 22:06
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-user] Erroneous deadlock detected???
>
>
> Well, it would seem to me that a ThreadLocal instance could help solve
> this problem. If one thread tries to acquire a lock it already owns, it
> ought to get it, right?
>
> If we were to apply the same semantics you describe to a simple Java
> class, then calling setX would always block...
>
> class C
> {
> synchronized void setX() {
> setY();
> }
> synchronized void setY() {
> ;
> }
> }
>
> If this is really the way JBoss works, and nobody knows a good reason
> why it should, can someone point me to the package/class responsible for
> this behavior and I'll take a whack at fixing it?
>
> Thanks,
> Jim
>
> On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
> > Explanation attempt inline.
> >
> > Regards,
> > Michael Bartmann
> >
> > Jim Crossley wrote:
> > > I have an MDB with the following pseudocode in its onMessage method:
> > >
> > > public void onMessage(Message msg)
> > > {
> > > // Entity bean = home.create(...)
> > > // bean.setX(...)
> > this starts a tx1 and locks the instance bean.
> > > // bean.setY(...)
> > this suspends the tx1 on bean temporarily,
> > and starts a tx2, which tries to obtain the lock on the bean, which it
>
> > will never get, because tx1 is not commited or rollbacked yet.
> > We had this problem under 2.4.4 w/o deadlock detection. Problem:
> > even the tx timeout didn't work in this case; the server locked
> forever... :-(
> > > }
> > >
> > > Each of the three methods, create, setX, and setY have a
> > > trans-attribute of "RequiresNew". With only one client posting a
> > > message, a "deadlock detected" exception is thrown when setX is
> > > invoked. How can deadlock occur when only one thread is active
> > >
> > > Thanks,
> > > Jim
> > >
> > >
> > >
> > >
> > > ---
> > > This sf.net email is sponsored by: Influence the future
> > > of Java(TM) technology. Join the Java Community
> > > Process(SM) (JCP(SM)) program now.
> > >
> http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javav
> ote
> > > ___
> > > JBoss-user mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-user
> > >
> >
> >
> >
> > ---
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
>
RE: [JBoss-user] Erroneous deadlock detected???
I ran into this same problem a while ago, and I suggested the same (at
least the thread, that holds the lock, should not be locked out).
Somebody wrote a 'SimpleReadWriteEJBLock' class, that seems to achieve
exactly this, but I could not find any info related to it.
You can also try to play around with the method attribute read-only
setting in jboss.xml (see the DTD).
To get better concurrency you may consider switching to the Instance Per
Transaction configuration (see standardjboss.xml) .
The QueuedPessimisticEJBLock does not make any sense with CMP, IMHO (if
you use it, it turns JBoss into a single tasking system).
Georg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Jim
Crossley
Sent: Thursday, October 24, 2002 22:06
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Erroneous deadlock detected???
Well, it would seem to me that a ThreadLocal instance could help solve
this problem. If one thread tries to acquire a lock it already owns, it
ought to get it, right?
If we were to apply the same semantics you describe to a simple Java
class, then calling setX would always block...
class C
{
synchronized void setX() {
setY();
}
synchronized void setY() {
;
}
}
If this is really the way JBoss works, and nobody knows a good reason
why it should, can someone point me to the package/class responsible for
this behavior and I'll take a whack at fixing it?
Thanks,
Jim
On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
> Explanation attempt inline.
>
> Regards,
> Michael Bartmann
>
> Jim Crossley wrote:
> > I have an MDB with the following pseudocode in its onMessage method:
> >
> > public void onMessage(Message msg)
> > {
> > // Entity bean = home.create(...)
> > // bean.setX(...)
> this starts a tx1 and locks the instance bean.
> > // bean.setY(...)
> this suspends the tx1 on bean temporarily,
> and starts a tx2, which tries to obtain the lock on the bean, which it
> will never get, because tx1 is not commited or rollbacked yet.
> We had this problem under 2.4.4 w/o deadlock detection. Problem:
> even the tx timeout didn't work in this case; the server locked
forever... :-(
> > }
> >
> > Each of the three methods, create, setX, and setY have a
> > trans-attribute of "RequiresNew". With only one client posting a
> > message, a "deadlock detected" exception is thrown when setX is
> > invoked. How can deadlock occur when only one thread is active
> >
> > Thanks,
> > Jim
> >
> >
> >
> >
> > ---
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
> >
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javav
ote
> > ___
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
>
>
> ---
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Erroneous deadlock detected???
Hi Jim,
Try adding this to server/default/conf/log4j.xml
And remove this from the file appender if it is there
Run your MDB and look in
server/default/log/server.log
You will see where transactions start and stop
[org.jboss.ejb.plugins.TxInterceptorCMT]
RequiresNew should commit on the return stroke of the
invocation.
Regards,
Adrian
From: Michael Bartmann <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Erroneous deadlock detected???
Date: Thu, 24 Oct 2002 23:36:13 +0200
Jim Crossley wrote:
Upon re-reading this, I got confused...
On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
{
// Entity bean = home.create(...)
// bean.setX(...)
this starts a tx1 and locks the instance bean.
Yes, but wouldn't the lock be released as soon as setX returns???
Good point; you got me. :-)
I'm not exactly sure about the semantics at this point; the
incident I refered to in my first comment involved a nested call.
This might depend on the tx markup of the outer method.
Regards,
Michael
// bean.setY(...)
this suspends the tx1 on bean temporarily,
and starts a tx2, which tries to obtain the lock on the bean,
I wouldn't think tx1 would need suspension as it has already completed,
right?
which it will never get, because tx1 is not commited or rollbacked
yet.
What event would cause the commit or rollback? I was thinking that, for
a trans-attribute of "RequiresNew", tx1 would be committed as soon as
setX returns.
Still confused,
Jim
---
This sf.net email is sponsored by: Influence the future of Java(TM)
technology. Join the Java Community Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future of Java(TM)
technology. Join the Java Community Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Erroneous deadlock detected???
Jim Crossley wrote:
Upon re-reading this, I got confused...
On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
{
// Entity bean = home.create(...)
// bean.setX(...)
this starts a tx1 and locks the instance bean.
Yes, but wouldn't the lock be released as soon as setX returns???
Good point; you got me. :-)
I'm not exactly sure about the semantics at this point; the
incident I refered to in my first comment involved a nested call.
This might depend on the tx markup of the outer method.
Regards,
Michael
// bean.setY(...)
this suspends the tx1 on bean temporarily,
and starts a tx2, which tries to obtain the lock on the bean,
I wouldn't think tx1 would need suspension as it has already completed,
right?
which it will never get, because tx1 is not commited or rollbacked
yet.
What event would cause the commit or rollback? I was thinking that, for
a trans-attribute of "RequiresNew", tx1 would be committed as soon as
setX returns.
Still confused,
Jim
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Erroneous deadlock detected???
Jim Crossley wrote:
Well, it would seem to me that a ThreadLocal instance could help solve
this problem. If one thread tries to acquire a lock it already owns, it
ought to get it, right
No, the lock belongs to the tx! This is exactly the semantic you request with
"RequiresNew". The ThreadLocal exists, but the suspend on tx1 takes the association
out of the ThreadLocal and associates a new tx2 with the thread.
If we were to apply the same semantics you describe to a simple Java
class, then calling setX would always block...
class C
{
synchronized void setX() {
setY();
}
synchronized void setY() {
;
}
}
If this is really the way JBoss works, and nobody knows a good reason
why it should, can someone point me to the package/class responsible for
this behavior and I'll take a whack at fixing it?
I think there might be something to fix with your tx markup.
Change "RequiresNew" to "Requires", so the same tx will get used
throughout your call.
Thanks,
Jim
On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
Explanation attempt inline.
Regards,
Michael Bartmann
Jim Crossley wrote:
I have an MDB with the following pseudocode in its onMessage method:
public void onMessage(Message msg)
{
// Entity bean = home.create(...)
// bean.setX(...)
this starts a tx1 and locks the instance bean.
// bean.setY(...)
this suspends the tx1 on bean temporarily,
and starts a tx2, which tries to obtain the lock on the bean,
which it will never get, because tx1 is not commited or rollbacked
yet.
We had this problem under 2.4.4 w/o deadlock detection. Problem:
even the tx timeout didn't work in this case; the server locked forever... :-(
}
Each of the three methods, create, setX, and setY have a trans-attribute
of "RequiresNew". With only one client posting a message, a "deadlock
detected" exception is thrown when setX is invoked. How can deadlock
occur when only one thread is active
Thanks,
Jim
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Erroneous deadlock detected???
Explanation attempt inline.
Regards,
Michael Bartmann
Jim Crossley wrote:
I have an MDB with the following pseudocode in its onMessage method:
public void onMessage(Message msg)
{
// Entity bean = home.create(...)
// bean.setX(...)
this starts a tx1 and locks the instance bean.
// bean.setY(...)
this suspends the tx1 on bean temporarily,
and starts a tx2, which tries to obtain the lock on the bean,
which it will never get, because tx1 is not commited or rollbacked
yet.
We had this problem under 2.4.4 w/o deadlock detection. Problem:
even the tx timeout didn't work in this case; the server locked forever... :-(
}
Each of the three methods, create, setX, and setY have a trans-attribute
of "RequiresNew". With only one client posting a message, a "deadlock
detected" exception is thrown when setX is invoked. How can deadlock
occur when only one thread is active
Thanks,
Jim
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Erroneous deadlock detected???
Well, it would seem to me that a ThreadLocal instance could help solve
this problem. If one thread tries to acquire a lock it already owns, it
ought to get it, right?
If we were to apply the same semantics you describe to a simple Java
class, then calling setX would always block...
class C
{
synchronized void setX() {
setY();
}
synchronized void setY() {
;
}
}
If this is really the way JBoss works, and nobody knows a good reason
why it should, can someone point me to the package/class responsible for
this behavior and I'll take a whack at fixing it?
Thanks,
Jim
On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
> Explanation attempt inline.
>
> Regards,
> Michael Bartmann
>
> Jim Crossley wrote:
> > I have an MDB with the following pseudocode in its onMessage method:
> >
> > public void onMessage(Message msg)
> > {
> > // Entity bean = home.create(...)
> > // bean.setX(...)
> this starts a tx1 and locks the instance bean.
> > // bean.setY(...)
> this suspends the tx1 on bean temporarily,
> and starts a tx2, which tries to obtain the lock on the bean,
> which it will never get, because tx1 is not commited or rollbacked
> yet.
> We had this problem under 2.4.4 w/o deadlock detection. Problem:
> even the tx timeout didn't work in this case; the server locked forever... :-(
> > }
> >
> > Each of the three methods, create, setX, and setY have a trans-attribute
> > of "RequiresNew". With only one client posting a message, a "deadlock
> > detected" exception is thrown when setX is invoked. How can deadlock
> > occur when only one thread is active
> >
> > Thanks,
> > Jim
> >
> >
> >
> >
> > ---
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
> > http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
> > ___
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
>
>
> ---
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Erroneous deadlock detected???
Upon re-reading this, I got confused...
On Thu, 2002-10-24 at 15:40, Michael Bartmann wrote:
> > {
> > // Entity bean = home.create(...)
> > // bean.setX(...)
> this starts a tx1 and locks the instance bean.
Yes, but wouldn't the lock be released as soon as setX returns???
> > // bean.setY(...)
> this suspends the tx1 on bean temporarily,
> and starts a tx2, which tries to obtain the lock on the bean,
I wouldn't think tx1 would need suspension as it has already completed,
right?
> which it will never get, because tx1 is not commited or rollbacked
> yet.
What event would cause the commit or rollback? I was thinking that, for
a trans-attribute of "RequiresNew", tx1 would be committed as soon as
setX returns.
Still confused,
Jim
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
