On Jun 1, 2008, at 6:39 PM, arashf wrote:
> > hi mike, > thanks for the response. at high traffic levels, the repeated > connecting/disconnecting have visible performance impact, no? Not at all. A checkout without any existing connection bound to the thread takes something like 30 function calls (a checkout with an already-thread-associated connection is like 5 function calls). It's completely miniscule to do a full checkout once per request (or even five or six times per request). It might add up to a second or two per 10K requests. > 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? If you want to use the SingletonThreadPool with no size limit, that will permanently bind each connection to the current thread. Its designed for sqlite and would not allow you to open a second connection on the same thread (which you'd want to do if you wanted to have two transactions simultaneously, for example), but if you really wanted to you could have a second engine for that purpose. You'd definitely would want to ensure that the app environment you're using has a fixed pool of threads which is never size-managed. I find this approach to be fairly brittle myself and I'd opt for an explicit connection setup/teardown 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 -~----------~----~----~----~------~----~------~--~---
