Alex:
A common cause of deadlocks is the following. A first thread reads a
record and later attempts to update it, but a second thread has been
allowed to read the record in between. Both threads are waiting on one
another to complete their transactions. The immediate cause of the problem
is that the locks that reads put on the records are merely read locks, not
update locks. If reads were to put update locks on the records, then after
a first thread reads a record, any subsequent threads attempting to read
the same records will be blocked, and the initial thread's attempts to
obtain an update lock for updating the records is guaranteed to succeed,
and, provided the first thread completes its transactions in a timely
fashion, the subsequent threads will be allowed to proceed with their work
in turn. How you can ensure that reads yield update locks in your
particular case will depend on your database.
Craig McMurtry
Toronto
Alex Paransky
<apara@standards To: [EMAIL PROTECTED]
et.com> cc:
Sent by: A Subject: Re: The problem with
deadlocking transactions...
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@JA
VA.SUN.COM>
05/05/2002 02:29
PM
Please respond
to apara
The exception which I am seeing looks like this:
com.evermind[Orion/1.5.3 (build 10509)].server.DeadlockException: Deadlock
detected, timing out call after 5 seconds wait
at com.evermind[Orion/1.5.3 (build
10509)].server.ejb.AbstractEJBObject.startCall(.:151)
at ComponentTypeEntityHome_EntityHomeWrapper99.findAll
<...removed a long trace...>
Normally, this page takes 1 second to return back. Click and it's back. I
can duplicate this problem pretty easily by going nuts with the mouse
button. If I click at the rate of 10 clicks per second, the problem always
occurs.
The other issue, is that the server never really recovers. Other users can
continue to use the application, however, the same user trying to login
again gets deadlock problems. I think this might be a bug in the server I
am using.
The database I am connecting to is PostresSQL 7.1.
I have already set the timeout to 5 seconds, but it does not appear to be
recovering.
Thanks for your help.
-AP_
-----Original Message-----
From: Keith Sterling [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 05, 2002 11:13 AM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: The problem with deadlocking transactions...
The problem might not actually be a deadlock, but your transaction timeout.
Are you using native locking in the database with select xxxx for update or
expecting the Application Server to lock the object.
Everytime the use clicks his browser a new session is created between the
browser and the servlet. The previous session is ignored, but will continue
until it exits. Anything it writes to output is just ignored and not
returned to the browser. Only the most recent click session can return to
the browser.
So what you are probably seeing is a build up of sessions, all trying to
access the same information. If this takes a long time, say n seconds, then
the second session will be 2 x n seconds, the third 3 x n, until you
session
m x n seconds.
Have you left it long enough for your sessions to either timeout, where you
will see a javax.transaction.TransactionException get thrown, or for your
clicked session to eventually return
You might want to use the setTimeout() on the transaction object you are
creating to something less than the standard 15 seconds
Perhaps you could also give us more detail of the access you are doing and
how you are doing it. What database are you accessing, are you using raw
JNDI or Database specific etc etc
Keith
-------------------------------------------------------------------------
Keith Sterling
Jacobs Rimell
VP of Engineering
Jacobs Rimell Ltd
24 Chiswell St
London EC1Y 4TY
Tel : +44 207 786 4000
Mob : +44 7771 597 630
Fax : +44 207 786 4004
http://www.jacobsrimell.com
-------------------------------------------------------------------------
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. If you are not the intended recipient, please
inform the sender and delete the email immediately.
WARNING:
It is impossible to guarantee the content of this message when it is
delivered across the internet, therefore the sender accepts no liability
for any claims arising from the information contained.
-----Original Message-----
From: Alex Paransky [mailto:[EMAIL PROTECTED]]
Sent: 05 May 2002 19:13
To: [EMAIL PROTECTED]
Subject: Re: The problem with deadlocking transactions...
I understand what you are saying in the first possible solution. However,
in this case the user is clicking on the same link. There are multiple
requests which are being fired off at the same time. The access is the
same, since it's the same link that is being pressed.
The second solution would work at the cost of having to maintain duplicate
code. The navigation relationships and security management are quite
difficult, thus I would have to duplicate a lot of complicated code.
I am wondering if this is a bug on the application server.
-AP_
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Mike Bresnahan
Sent: Sunday, May 05, 2002 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: The problem with deadlocking transactions...
> When we wrap a transaction around our read operations the
> container does not
> have to ejbLoad/ejbStore for every call into the entity bean, however, we
> noticed that users clicking on the same link in the browser in rapid
> succession create multiple requests which all promptly deadlock on each
> other.
First possible solution: Analyze your data access paths and see if you can
ensure that users always access data in the same order. For example, given
entities X and Y, make sure that users always lock X and then Y. If you
can
do this, you can eliminate the possibility of a deadlock.
Second possible solution: Use a lightweight mechanism for read-only data.
I.e. don't use EJBs for data that you are only reading, use a Data Access
Object instead.
Mike Bresnahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
