You could try using your own wrappers on the JDBC classes ala this article
http://www.onjava.com/lpt/a/onjava/2001/12/05/optimization.html Then, you can see exactly what Orion is calling. At least that helps track the bug down a bit. Actually, maybe you could use this method to force Oracle to clean itself up better? That is, to enforce the contract of the Connection.close() method (as pointed out in Avi's email that you forwarded to the list). Actually, if what he says is true, maybe all us Oracle users could use some wrappers like that! :-) Cheers geoff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Hubbach Sent: Wednesday, January 30, 2002 3:44 AM To: Orion-Interest Subject: Container leaving Dirty Connection in CMP with container-managed transactions If an exception is thrown in a CMP entity bean with container-managed transactions, a Dirty Connection is left behind that is never cleaned up (or at least in 15 minutes). We've set inactivity-timeout in the data-sources and tweaked with all the transaction settings, all to no avail. Is anyone experiencing this? It does this with Oracle (running Oracle's driver as well as Merant's), PostgreSQL, and SQL Server (running Merant's driver). The biggest issue is that the dirty connection in Oracle and SQL Server is holding a lock to the row that caused the exception, preventing any further access, actually deadlocking the server (in PostgreSQL, further updates to that row go through just fine). Or at least this is what we _think_ is happening, as there's no better explanation that we've found. Jeff.
