Hi,
ivanhoe Abrahams wrote:
> Could anyone point me in the right direction when it comes to solving
> the LOCKING-WAITING problem
> It hangs my client/keeps the server so busy that everything slows down
> to a snail's pace.
In the current CVS version of JBoss is a partial fix for that and
some developers are just working on the final fix. I didn't try
the partial fix yet, if you do, it would be nice to report back
to the list (or at least to me) how it changes behaviour.
> Ps. a good explanation of the problem (a deadlock I assume) would be
> interesting to chew on.
Essentially quoting from one of my previous mails:
----- begin quote -----
simplest deadlock scenario:
time Session/TX A Session/TX B
---- -------------------- -------------
T1 access Entity 1
T2 access Entity 2
T3 try access Entity 2,
must wait for TX B
to finish
T4 try access Entity 1,
must wait for TX A
to finish
^^^^^^^^^^^^^^^^^^^
this deadlocks, each session/Tx
waiting for the other to complete.
> Is there a nice way to handle this, or an easy way to debug it? Or is
> this going to be a nightmare to fix?
The only thing to do about that with the current EJB spec is to try
to access ALL deadlock prone beans in the same order (see the 'dining
philosophers problem' in the JAVA tutorial). I.e. you could attempt
to access them in increasing Primary Key order from all clients.
In the above example the session/TX B then would try to get Entity 1
first before accessing Entity 2, waiting there, and session/TX A
could complete.
In real world, this ordered access, even with moderately complex
applications, seems near to impossible to implement, especially
if you allow interactive access to several lock prone resources
in one (long lived) transaction, where you can't control the order.
In such cases there exists a well defined protocol in the
relational world, that has proven to work very well and can be
followed by any client. It's based on locking all deadlock prone
resources before doing any modification and GIVING UP ALL LOCKS,
when one lock can't be obtained, thus allowing other clients to
proceed.
But the EJB spec is mostly silent about locking, there is no
requirement at all to support lock detection (besides timeout
with distributed TX), thus you can't follow that with EJB.
----- end quote -----
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
