Re[2]: EJB Deadlocks????
Hello Jeff, i am not very sophisticated user of Orion, if you make only read you should check for something like updating of ejb`s instance`s in Orion. There should be a method specific for Entity EJB which stating that this instance of ejb is not for update in database (something like isUpdated or other like this), because it is not clean that your ejb after loading is not updated in your code and orion tries to update database. This is solution specific to Orion i think, other vendors, should have like this. JH Stephen, JH We found a deadlock problem, but you don't need a heavy load to achieve it. I'll describe the situation to you and you can decide if it's the same error or not. JH A session bean with container-managed transactions does updates to 2 entity beans. If _ANY_ error is thrown while updating the second entity bean, then the transaction is rolled back (as it JH should, and as we coded it to). The deadlock happens when you try to access the specific entity that was updated first in that failed transaction. The server just hangs at the ejbStore() call of JH that entity. We've duplicated this problem on Oracle 8, 8i, SQL Server 7, and someone else duplicated it on SAP and DB2. For some reason it works on PostgreSQL. We don't know if it's a result of JH the Dirty Connection that you see is left behind if you have -Djdbc.debug=true. JH I have a test case, and we've posted a bug (#702). We've discussed this on elephantwalker, etc. and 1.5.4 doesn't correct the problem. My guess is that noone seems to think it's a big deal, which JH I find hard to believe. If this sounds like a possible way that you're achieving your deadlock (ie, you're updating multiple beans in a transaction that has the possibility of being rolled back, JH then you try to update one of those beans again), then I'd love it if you'd help me jump and scream and get someone, preferably magnus, to acknowledge this problem and fix it. JH If anyone would like our test case, please email me and I'd be happy to send it your way. JH Jeff. JH On Thu, 21 Feb 2002 15:33:38 -0600 JH Stephen Davidson [EMAIL PROTECTED] wrote: Greetings. I am running a load test on a system with 200 concurrent threads (simulating 200 concurrent users). System requirements are for 1000 Users/box. When running the test, I hit the attached Error. Has anyone else been having problems with Orion under heavy loads? -Steve 500 Internal Server Error com.evermind[Orion/1.5.4 (build 10585)].server.DeadlockException: Deadlock detected, timing out call after 90 seconds wait for thread Thread[ApplicationServerThread,5,applicationServerThreadGroup] at com.evermind[Orion/1.5.4 (build 10585)].server.ejb.AbstractEJBObject.startCall(.:149) at User_EntityBeanWrapper36.getUserId(User_EntityBeanWrapper36.java:889) at com.hrnexus.security.shared.ThinUserProxy.getUserId(ThinUserProxy.java:111) at /site_header.jsp._jspService(/site_header.jsp.java:105) (JSP page line 101) at com.orionserver[Orion/1.5.4 (build 10585)].http.OrionHttpJspPage.service(.:56) at com.evermind[Orion/1.5.4 (build 10585)]._cp._vhc(.:5639) at com.evermind[Orion/1.5.4 (build 10585)].server.http.JSPServlet.service(.:31) at com.evermind[Orion/1.5.4 (build 10585)]._deb._lnc(.:514) at com.evermind[Orion/1.5.4 (build 10585)]._deb._wmb(.:170) at com.evermind[Orion/1.5.4 (build 10585)]._co._wbb(.:581) at com.evermind[Orion/1.5.4 (build 10585)]._co._fs(.:189) at com.evermind[Orion/1.5.4 (build 10585)]._bt.run(.:62) -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208 Best regards, slyncemailto:[EMAIL PROTECTED]
Re: EJB Deadlocks????
Hi Guys. This is a little different from Bug #702. The is only one Entity Bean involved, and he is not doing much in way of updating. This bug actually occured during a read, not an update. I have not heard anything more from anyone on this issue. -Steve [EMAIL PROTECTED] wrote: Hello Jeff, i am not very sophisticated user of Orion, if you make only read you should check for something like updating of ejb`s instance`s in Orion. There should be a method specific for Entity EJB which stating that this instance of ejb is not for update in database (something like isUpdated or other like this), because it is not clean that your ejb after loading is not updated in your code and orion tries to update database. This is solution specific to Orion i think, other vendors, should have like this. JH Stephen, JH We found a deadlock problem, but you don't need a heavy load to achieve it. I'll describe the situation to you and you can decide if it's the same error or not. JH A session bean with container-managed transactions does updates to 2 entity beans. If _ANY_ error is thrown while updating the second entity bean, then the transaction is rolled back (as it JH should, and as we coded it to). The deadlock happens when you try to access the specific entity that was updated first in that failed transaction. The server just hangs at the ejbStore() call of JH that entity. We've duplicated this problem on Oracle 8, 8i, SQL Server 7, and someone else duplicated it on SAP and DB2. For some reason it works on PostgreSQL. We don't know if it's a result of JH the Dirty Connection that you see is left behind if you have -Djdbc.debug=true. JH I have a test case, and we've posted a bug (#702). We've discussed this on elephantwalker, etc. and 1.5.4 doesn't correct the problem. My guess is that noone seems to think it's a big deal, which JH I find hard to believe. If this sounds like a possible way that you're achieving your deadlock (ie, you're updating multiple beans in a transaction that has the possibility of being rolled back, JH then you try to update one of those beans again), then I'd love it if you'd help me jump and scream and get someone, preferably magnus, to acknowledge this problem and fix it. JH If anyone would like our test case, please email me and I'd be happy to send it your way. JH Jeff. JH On Thu, 21 Feb 2002 15:33:38 -0600 JH Stephen Davidson [EMAIL PROTECTED] wrote: Greetings. I am running a load test on a system with 200 concurrent threads (simulating 200 concurrent users). System requirements are for 1000 Users/box. When running the test, I hit the attached Error. Has anyone else been having problems with Orion under heavy loads? -Steve 500 Internal Server Error com.evermind[Orion/1.5.4 (build 10585)].server.DeadlockException: Deadlock detected, timing out call after 90 seconds wait for thread Thread[ApplicationServerThread,5,applicationServerThreadGroup] at com.evermind[Orion/1.5.4 (build 10585)].server.ejb.AbstractEJBObject.startCall(.:149) at User_EntityBeanWrapper36.getUserId(User_EntityBeanWrapper36.java:889) at com.hrnexus.security.shared.ThinUserProxy.getUserId(ThinUserProxy.java:111) at /site_header.jsp._jspService(/site_header.jsp.java:105) (JSP page line 101) at com.orionserver[Orion/1.5.4 (build 10585)].http.OrionHttpJspPage.service(.:56) at com.evermind[Orion/1.5.4 (build 10585)]._cp._vhc(.:5639) at com.evermind[Orion/1.5.4 (build 10585)].server.http.JSPServlet.service(.:31) at com.evermind[Orion/1.5.4 (build 10585)]._deb._lnc(.:514) at com.evermind[Orion/1.5.4 (build 10585)]._deb._wmb(.:170) at com.evermind[Orion/1.5.4 (build 10585)]._co._wbb(.:581) at com.evermind[Orion/1.5.4 (build 10585)]._co._fs(.:189) at com.evermind[Orion/1.5.4 (build 10585)]._bt.run(.:62) -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208 Best regards, slyncemailto:[EMAIL PROTECTED] -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
Re: EJB Deadlocks????
Hi Jeff. I was not doing, an Update, I was doing READs! Which is probably why I needed a heavier load than you did before it showed up. One of our test servers is exposed to the internet, so I can set up a test case on that if people want to check it out. I am running Orion 1.5.4. -Steve Jeff Hubbach wrote: Stephen, We found a deadlock problem, but you don't need a heavy load to achieve it. I'll describe the situation to you and you can decide if it's the same error or not. A session bean with container-managed transactions does updates to 2 entity beans. If _ANY_ error is thrown while updating the second entity bean, then the transaction is rolled back (as it should, and as we coded it to). The deadlock happens when you try to access the specific entity that was updated first in that failed transaction. The server just hangs at the ejbStore() call of that entity. We've duplicated this problem on Oracle 8, 8i, SQL Server 7, and someone else duplicated it on SAP and DB2. For some reason it works on PostgreSQL. We don't know if it's a result of the Dirty Connection that you see is left behind if you have -Djdbc.debug=true. I have a test case, and we've posted a bug (#702). We've discussed this on elephantwalker, etc. and 1.5.4 doesn't correct the problem. My guess is that noone seems to think it's a big deal, which I find hard to believe. If this sounds like a possible way that you're achieving your deadlock (ie, you're updating multiple beans in a transaction that has the possibility of being rolled back, then you try to update one of those beans again), then I'd love it if you'd help me jump and scream and get someone, preferably magnus, to acknowledge this problem and fix it. If anyone would like our test case, please email me and I'd be happy to send it your way. Jeff. On Thu, 21 Feb 2002 15:33:38 -0600 Stephen Davidson [EMAIL PROTECTED] wrote: Greetings. I am running a load test on a system with 200 concurrent threads (simulating 200 concurrent users). System requirements are for 1000 Users/box. When running the test, I hit the attached Error. Has anyone else been having problems with Orion under heavy loads? -Steve 500 Internal Server Error com.evermind[Orion/1.5.4 (build 10585)].server.DeadlockException: Deadlock detected, timing out call after 90 seconds wait for thread Thread[ApplicationServerThread,5,applicationServerThreadGroup] at com.evermind[Orion/1.5.4 (build 10585)].server.ejb.AbstractEJBObject.startCall(.:149) at User_EntityBeanWrapper36.getUserId(User_EntityBeanWrapper36.java:889) at com.hrnexus.security.shared.ThinUserProxy.getUserId(ThinUserProxy.java:111) at /site_header.jsp._jspService(/site_header.jsp.java:105) (JSP page line 101) at com.orionserver[Orion/1.5.4 (build 10585)].http.OrionHttpJspPage.service(.:56) at com.evermind[Orion/1.5.4 (build 10585)]._cp._vhc(.:5639) at com.evermind[Orion/1.5.4 (build 10585)].server.http.JSPServlet.service(.:31) at com.evermind[Orion/1.5.4 (build 10585)]._deb._lnc(.:514) at com.evermind[Orion/1.5.4 (build 10585)]._deb._wmb(.:170) at com.evermind[Orion/1.5.4 (build 10585)]._co._wbb(.:581) at com.evermind[Orion/1.5.4 (build 10585)]._co._fs(.:189) at com.evermind[Orion/1.5.4 (build 10585)]._bt.run(.:62) -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208 -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
Re: EJB Deadlocks????
I ran this test case against Oracle 9i using 1.5.4 and no changes to any orion-ejb-jar.xml files and it worked like a charm. The other database that I use, SAP DB fails (hangs). With 1.5.3 both Oracle and SAP DB failed. So I think some items have been fixed - and I also am now looking at what happens on the database side. Think I'll look at SAP DB's JDBC driver and see how it handles these errors. Cheers Ray --- Jeff Hubbach [EMAIL PROTECTED] wrote: Stephen, We found a deadlock problem, but you don't need a heavy load to achieve it. I'll describe the situation to you and you can decide if it's the same error or not. A session bean with container-managed transactions does updates to 2 entity beans. If _ANY_ error is thrown while updating the second entity bean, then the transaction is rolled back (as it should, and as we coded it to). The deadlock happens when you try to access the specific entity that was updated first in that failed transaction. The server just hangs at the ejbStore() call of that entity. We've duplicated this problem on Oracle 8, 8i, SQL Server 7, and someone else duplicated it on SAP and DB2. For some reason it works on PostgreSQL. We don't know if it's a result of the Dirty Connection that you see is left behind if you have -Djdbc.debug=true. I have a test case, and we've posted a bug (#702). We've discussed this on elephantwalker, etc. and 1.5.4 doesn't correct the problem. My guess is that noone seems to think it's a big deal, which I find hard to believe. If this sounds like a possible way that you're achieving your deadlock (ie, you're updating multiple beans in a transaction that has the possibility of being rolled back, then you try to update one of those beans again), then I'd love it if you'd help me jump and scream and get someone, preferably magnus, to acknowledge this problem and fix it. If anyone would like our test case, please email me and I'd be happy to send it your way. Jeff. On Thu, 21 Feb 2002 15:33:38 -0600 Stephen Davidson [EMAIL PROTECTED] wrote: Greetings. I am running a load test on a system with 200 concurrent threads (simulating 200 concurrent users). System requirements are for 1000 Users/box. When running the test, I hit the attached Error. Has anyone else been having problems with Orion under heavy loads? -Steve 500 Internal Server Error com.evermind[Orion/1.5.4 (build 10585)].server.DeadlockException: Deadlock detected, timing out call after 90 seconds wait for thread Thread[ApplicationServerThread,5,applicationServerThreadGroup] at com.evermind[Orion/1.5.4 (build 10585)].server.ejb.AbstractEJBObject.startCall(.:149) at User_EntityBeanWrapper36.getUserId(User_EntityBeanWrapper36.java:889) at com.hrnexus.security.shared.ThinUserProxy.getUserId(ThinUserProxy.java:111) at /site_header.jsp._jspService(/site_header.jsp.java:105) (JSP page line 101) at com.orionserver[Orion/1.5.4 (build 10585)].http.OrionHttpJspPage.service(.:56) at com.evermind[Orion/1.5.4 (build 10585)]._cp._vhc(.:5639) at com.evermind[Orion/1.5.4 (build 10585)].server.http.JSPServlet.service(.:31) at com.evermind[Orion/1.5.4 (build 10585)]._deb._lnc(.:514) at com.evermind[Orion/1.5.4 (build 10585)]._deb._wmb(.:170) at com.evermind[Orion/1.5.4 (build 10585)]._co._wbb(.:581) at com.evermind[Orion/1.5.4 (build 10585)]._co._fs(.:189) at com.evermind[Orion/1.5.4 (build 10585)]._bt.run(.:62) -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208 -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114 __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
EJB Deadlocks????
Greetings. I am running a load test on a system with 200 concurrent threads (simulating 200 concurrent users). System requirements are for 1000 Users/box. When running the test, I hit the attached Error. Has anyone else been having problems with Orion under heavy loads? -Steve 500 Internal Server Error com.evermind[Orion/1.5.4 (build 10585)].server.DeadlockException: Deadlock detected, timing out call after 90 seconds wait for thread Thread[ApplicationServerThread,5,applicationServerThreadGroup] at com.evermind[Orion/1.5.4 (build 10585)].server.ejb.AbstractEJBObject.startCall(.:149) at User_EntityBeanWrapper36.getUserId(User_EntityBeanWrapper36.java:889) at com.hrnexus.security.shared.ThinUserProxy.getUserId(ThinUserProxy.java:111) at /site_header.jsp._jspService(/site_header.jsp.java:105) (JSP page line 101) at com.orionserver[Orion/1.5.4 (build 10585)].http.OrionHttpJspPage.service(.:56) at com.evermind[Orion/1.5.4 (build 10585)]._cp._vhc(.:5639) at com.evermind[Orion/1.5.4 (build 10585)].server.http.JSPServlet.service(.:31) at com.evermind[Orion/1.5.4 (build 10585)]._deb._lnc(.:514) at com.evermind[Orion/1.5.4 (build 10585)]._deb._wmb(.:170) at com.evermind[Orion/1.5.4 (build 10585)]._co._wbb(.:581) at com.evermind[Orion/1.5.4 (build 10585)]._co._fs(.:189) at com.evermind[Orion/1.5.4 (build 10585)]._bt.run(.:62) -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
Re: EJB Deadlocks????
Stephen, We found a deadlock problem, but you don't need a heavy load to achieve it. I'll describe the situation to you and you can decide if it's the same error or not. A session bean with container-managed transactions does updates to 2 entity beans. If _ANY_ error is thrown while updating the second entity bean, then the transaction is rolled back (as it should, and as we coded it to). The deadlock happens when you try to access the specific entity that was updated first in that failed transaction. The server just hangs at the ejbStore() call of that entity. We've duplicated this problem on Oracle 8, 8i, SQL Server 7, and someone else duplicated it on SAP and DB2. For some reason it works on PostgreSQL. We don't know if it's a result of the Dirty Connection that you see is left behind if you have -Djdbc.debug=true. I have a test case, and we've posted a bug (#702). We've discussed this on elephantwalker, etc. and 1.5.4 doesn't correct the problem. My guess is that noone seems to think it's a big deal, which I find hard to believe. If this sounds like a possible way that you're achieving your deadlock (ie, you're updating multiple beans in a transaction that has the possibility of being rolled back, then you try to update one of those beans again), then I'd love it if you'd help me jump and scream and get someone, preferably magnus, to acknowledge this problem and fix it. If anyone would like our test case, please email me and I'd be happy to send it your way. Jeff. On Thu, 21 Feb 2002 15:33:38 -0600 Stephen Davidson [EMAIL PROTECTED] wrote: Greetings. I am running a load test on a system with 200 concurrent threads (simulating 200 concurrent users). System requirements are for 1000 Users/box. When running the test, I hit the attached Error. Has anyone else been having problems with Orion under heavy loads? -Steve 500 Internal Server Error com.evermind[Orion/1.5.4 (build 10585)].server.DeadlockException: Deadlock detected, timing out call after 90 seconds wait for thread Thread[ApplicationServerThread,5,applicationServerThreadGroup] at com.evermind[Orion/1.5.4 (build 10585)].server.ejb.AbstractEJBObject.startCall(.:149) at User_EntityBeanWrapper36.getUserId(User_EntityBeanWrapper36.java:889) at com.hrnexus.security.shared.ThinUserProxy.getUserId(ThinUserProxy.java:111) at /site_header.jsp._jspService(/site_header.jsp.java:105) (JSP page line 101) at com.orionserver[Orion/1.5.4 (build 10585)].http.OrionHttpJspPage.service(.:56) at com.evermind[Orion/1.5.4 (build 10585)]._cp._vhc(.:5639) at com.evermind[Orion/1.5.4 (build 10585)].server.http.JSPServlet.service(.:31) at com.evermind[Orion/1.5.4 (build 10585)]._deb._lnc(.:514) at com.evermind[Orion/1.5.4 (build 10585)]._deb._wmb(.:170) at com.evermind[Orion/1.5.4 (build 10585)]._co._wbb(.:581) at com.evermind[Orion/1.5.4 (build 10585)]._co._fs(.:189) at com.evermind[Orion/1.5.4 (build 10585)]._bt.run(.:62) -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208 -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114
