hi mike, thanks for the response. at high traffic levels, the repeated connecting/disconnecting have visible performance impact, no? are there any other solutions available which still use the connection pool and somehow still holding a grip to the original connection so it's reused?
On Jun 1, 6:25 am, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Jun 1, 2008, at 8:11 AM, arashf wrote: > > > > > sorry for those on both the pylons/sqlalchemy lists. not sure what the > > best place for this is: > > > I'm seeing some interesting behavior with threadlocal sqlalchemy/ > > pylons. > > after a session.commit() the next connection used is different from > > the original despite the fact that the it's on the same thread/ > > request. isn't threadlocal was supposed to prevent this? > > no. when the connection proxy is closed, if no other actors within > that thread have a grip on that object, the underlying DBAPI > connection is back in the pool. the next checkout will return any > connection available from the pool. This is described at: > http://www.sqlalchemy.org/docs/04/dbengine.html#dbengine_implicit_str... > . > > > expected behavior, is there any straight forward way to keep the same > > connection or reacquire it? > > yes. Bind the Session to a specific connection at the start of the > request, and tear it down at the end. There is an example of this in > the Pylons > tutorialhttp://wiki.pylonshq.com/display/pylonsdocs/Using+SQLAlchemy+with+Pylons > - about 1/3rd into it, search for the string "to use just a single > database connection per request". --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
