Why doesn't the returnConnection method (either the threadsafe or threadunsafe implementation of it) call connection.rollback() before returning the connection to the pool?
As it is, this scenario could arise: A1: ask the DBPool for a connection A2: start a transaction implicitly by performing some database ops, and leave the transaction unresolved A3: return the connection (an instance of MiscUtils.DBPool.PooledConnection) to the pool with the close() method, which doesn't resolve the transaction B1: ask the DBPool for a connection (and get the same connection as in a1) B2: perform some database ops, unintentionally resuming the transaction started in A2 B3: commit the transaction, unintentionally comitting the operations performed in A2 I use a subclass of DBPool whose returnConnection method rolls back any unresolved transaction before placing the connection back in the available pool, so that a connection freshly allocated from the pool is guaranteed not to have a residual transaction. Is there a reason why the official DBPool shouldn't behave this way? __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
