Hi Clark,
My wish list for DBPool is:
1. Detect bad connections and re-create them.
2. Allow min and max connections. This would tie in nicely with your
expiration request. Maintain a minimum (could be zero) number of
connections and create up to maximum connections as needed which then
expire back down to the minimum over time.
I have a few layers on top of DbPool for PostgreSQL which I've wanted to
post but never took the time to make them ready for prime time. I'll
include a copy here anyway. I started with DatabaseMixin for SQL
Server, which I _think_ was written by Geoff, and started porting to
PostgreSQL.
Before I hand out a db connection, I do a rollback just in case the
previous user had left a transaction open. I hate spending the time to
send a 'rollback' but its the safest way I could think of and it gets
the connection out of transaction mode. <rant>I wish the python DB API
wouldn't start transactions. I'll start my own transactions when and if
I need them, thank you very much.</rant>
After stress testing with 20 concurrent requests, I found that my
database connection usage was not thread-safe and my servlets were
hanging while waiting for each other to release connections. To make
sure we don't make that mistake again, I made an atomic "recordset()"
method that doesn't make the connection available to the servlet code.
It also converts the records to objects that allow case-insensitive
dictionary lookup, case insensitive attribute lookup, and positional
lookup. It also converts timestamps to mx.DateTime objects. It has a
lame replacement for ODBC datasources too that I've wanted to improve.
from Database import Database
class SitePage(Database)
def test(self):
rs =3D self.recordset('accounting','select firstname from
users')
for r in rs:
print r.firstName
print r.firstname
print r['firstName']
print r[0]
Regards,
Jeff
> (non-urgent)
>=20
> I have a minor problem here... in the DB pool, when
> a connection is returned it may have one or more "active"=20
> transactions (esp when only used for selecting information). =20
> These transactions take up extra overhead in the database.
> Anyway... I'm too hammered with getting a product out
> that I don't have time to investigate... but I will
> invesigate and submit a patch in a few weeks when I=20
> have more time (beacuse I can't ship with this behavior).
>=20
> Either I can "bullet proof" all of my code to clean up
> the transaction; or we could fix DbPool to do this for us...
> I think the latter is the better "lazy-mans" solution.
> Thoughts? Also... I need some way where the number of=20
> connections will decrease to zero over time... say if=20
> the connection isn't used for 2-5 minutes.
>=20
|