Re: Default Connection Pooling

Jacob Smullyan <[email protected]> Sat, 13 Aug 2005 12:48:50 -0400
Newsgroups gmane.comp.web.skunkweb
Message-ID <[email protected]>
On Sat, Aug 13, 2005 at 09:18:23AM -0700, Matthew Bogosian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ah. Okay, I understand now. The PyDO connection object is just a proxy 
> to a real connection object (optionally via a connection pool). This 
> makes more sense to me now (thanks for the explanation).
> 
> I take it one should avoid accessing the underlying connection object 
> (e.g., via o.getDBI().conn) unless one really knows what one is 
> doing....

Not necessarily, it isn't a private attribute; but knowing what you
are doing is of course recommended.

What is somewhat odd is that you can do this whenever you feel like
getting rid of the connection and getting a new one:

  # bye-bye connection!
  del o.getDBI().conn
  # it's back!
  c=o.getDBI().conn.cursor()

There is also a swapConnection() method, if you want to switch from
one connection to another (in case you are managing connections
entirely outside of PyDO -- I was thinking this might be useful in
twisted or other situations where different multiple transactions need
to be dovetailed in the same thread).

js
> 
> 	-- Matt
> 
> 
> On Aug 13, 2005, at 08:36, Jacob Smullyan wrote:
> 
> >On Sat, Aug 13, 2005 at 07:43:36AM -0700, Matthew Bogosian wrote:
> >>Does this mean that one cannot call commit() or rollback() more than
> >>once on a given connection?
> >
> >If you've done so, why do you care whether the connection you have
> >after committing or rolling back is the same connection, or a
> >different one?  The transaction is over.  For it to matter, the
> >connection would need to have some state that you want to preserve
> >across transaction boundaries.  I don't see anything in your example
> >that would be a problem.
> >
> >The dbi object's "conn" attribute auto-vivifies.  If the connection is
> >returned to the pool, the next time you need it another equivalent one
> >is there.
> >
> >With mysql, if insert_id() is connection-specific state, that would
> >break with autocommit (which I still haven't had time to fix, sorry)
> >and maybe even without it, if you tried to call insert_id() after a
> >commit:
> >
> >   o=obj.new()
> >   o.commit()
> >   # what happens?
> >   print o.getDBI().conn.insert_id()
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (Darwin)
> 
> iD8DBQFC/h1PnLpDzL5I7l8RAm0NAJoDGRZ9UfB6A1+h3XcifUoUk4465wCgiDBO
> 99FvUy84Z6+9NzvdIlLmK/o=
> =vwhc
> -----END PGP SIGNATURE-----
> 

-- 
Jacob Smullyan


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf