Hi Alex What class are you using for writing html data from the serlvet?
PrintWriter? And does your servlet return any raw data like byte[], etc If yes, that could be the very reason for your deadlocks, server never returning, etc. PrintWriter caches the data and it encodes byte streams. Your heap size is going to increase when you click several times in succession and the cached data doesnt get cleaned up either. So, your server goes into this infinite loop and after a while, you just have to bring it down. Try using ServletOutputStream instead and let us know if that works. Regards Madhu -----Original Message----- From: Alex Paransky [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 05, 2002 2:29 PM To: [EMAIL PROTECTED] Subject: Re: The problem with deadlocking transactions... 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". =========================================================================== 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".
