--- Ben Parker <[EMAIL PROTECTED]> wrote:
> > 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?
>
> One short answer is that not all db's support transactional commit()
> and rollback()
try:
con.rollback()
except:
pass
> I think though that the issue you describe should be handled in
> the application code, not a connection framework. I would consider
> an unresolved transaction to be a bug.
There's some merit in that position ("explicit is better than
implicit"), but the Python DB API Spec 2.0 disagrees that it's a bug:
"""
Closing a connection without committing the changes first will cause an
implicit rollback to be performed.
"""
Advisable or not, the correctness of implicit rollback is codified in
the authoritative specification of the behavior of Python database
modules. My contention is that the MiscUtils.DBPool.PooledConnection
class is supposed to be a transparent proxy for DB Spec Connection
objects; therefore, the fact that the
MiscUtils.DBPool.PooledConnection.close method does not "cause an
implicit rollback to be performed" is a bug.
This isn't exactly the bugfix that I suggested in my first message--the
implicit rollback ought to be in
MiscUtils.DBPool.PooledConnection.close rather than my original
suggestion of MiscUtils.DBPool.returnConnection--but it has the same
effect.
> I brought up a related issue about a couple months ago in a post
> to this list.
[... issue with DBPool and threadsafety-3 DB modules...]
The essential difference between that case and this one is that the
Python DB API Spec doesn't explicitly mandate that MiscUtils.DBPool is
in error with regard to thread safety--it simply doesn't address the
issue you encountered.
> I have a homegrown db pool for use with DCOracle2 to get around this
> issue. I've come to the conclusion that pooling connections is highly
> dependent upon the db itself, the db interface, and one's
application.
Yes, but the DB API Spec covers this particular behavior; DBPool ought
to be made compliant with it insofar as possible. The DB API Spec
makes recommendations of how to deal with DB modules that don't support
transactions, and those are directly applicable to MiscUtils.DBPool.
__________________________________
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
