More developments... With -Djdbc.debug=true, the failed transaction leaves a Dirty Connection around on both Oracle and PostgreSQL, so I guess the next question is... what constitutes a Dirty Connection? and is that's what's causing the lock?
In further trials, we also tested updating that row that locks directly through sqlplus once the transaction failed. Even sqlplus hanged, with no error code/message. Because this works in PostgreSQL and not in Oracle or SQL Server, I'm not sure if it's an Orion problem, a JDBC driver problem, or a database problem. Does anyone out there have anything to add? similar problems? possible solutions (besides just changing the trans-attributes or orion caching settings, because believe me, we've tried them all and none of them fix the problem)? FYI, we've posted this in bugzilla as bug #702. Jeff. On Tue, 22 Jan 2002 10:38:02 -0700 Jeff Hubbach <[EMAIL PROTECTED]> wrote: > I'm hoping someone can give some insight as to why this is happening. I have a very >simple test case with one stateless session bean and 2 CMP entity beans. The session >bean just acts as a controller to modify the entity beans. All transactions are >container-managed at the session bean. The entity beans are very simple, one just has >a key and string, the other has a key, foreign key (referencing the first one) and >string. > > OK, here's the scenario: > Step 1. > JSP page creates a session bean, then calls updateBothBeans with values that >succeed. Everything goes as planned. > Step 2. > JSP page creates a session bean, then calls updateBothBeans with values that break >the foreign-key constraint of the second bean, but the first bean's update is called >first. We receive an OrionRemoteException and the update to the first bean is not >committed to the database. So far so good. > Step 3. > JSP page creates a session bean, then calls updateBothBeans with values that should >succeed. We receive a deadlock somewhere after where ejbStore is called on the first >bean and before ejbStore is called on the second bean. > > Transaction attributes are: > For updateBothBeans in the session bean - RequiresNew > For everything in the entity beans - Mandatory > I also tried setting the trans-attribute of ejbLoad in both entity beans to >NotSupported, with the same result. > > Why is this? As far as I can tell, it looks like the database is keeping a read-lock >on that row, but I have no idea where it's getting it from. By the way, I've tested >this on Oracle 8 and 8i, both with Oracle's JDBC drivers and Merant's JDBC drivers, >as well as SQL Server 2000 with Merant's JDBC drivers, all with the same result. When >tested with PostgreSQL 7.1.3, everything works. > > I would love to hear some insight or solution to this problem, as it's driving me >nuts. > > Thanks, > Jeff Hubbach. > -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114
