On Oct 7, 2010, at 12:53 AM, Warwick Prince wrote: > Hi Michael > > I'm still having a couple of issues with the sessions, but I'm now starting > to suspect mysqlconnector.. > > For completeness, could you please let me know if there is anything specific > I need to do to "close down" a session / connection / engine etc if I want to > completely release it. > > I see session.close(), but that appears to be more about committing etc, and > I can't see anything specific I need to do to an engine etc. Basically, I > just want to ensure that I'm doing everything correctly when I drop a session > and kill the thread that it was in.
close() releases any open connections to the connection pool, and since the pool has a limit, if you weren't returning things to the pool that would be apparent once the pool raises an error. > > Also, If I'm NOT creating lots of sessions for short periods of time (i.e. > web services) (which I'm not) do I need to consider pools for any specific > reason? They appear to be more about scaling that sort of situation. I'm > basically creating a session and hanging on to it - doing lots of queries, > updates etc with lots of commit/roll back, then dropping the session and > exiting some time later -- Is my interpretation of session use correct? you pretty much dont need to consider pools at all, just create an engine, use it. If you only use one connection at a time, the pool would only have one connection. > > I'll play with other avenues of investigation before bringing the current > session issues to the table. ;-) > > Cheers > Warwick > > >> >> On Oct 6, 2010, at 6:46 AM, Warwick Prince wrote: >> >>> >>> I can't quite get my head around the "scope" of sessionmaker() yet.. I've >>> tried putting Session = sessionmaker() as a global to the entire codebase >>> (works but has same problem) >> >> do you mean scoped_session here ? sessionmaker is just a constructor for a >> new Session. It doesn't hold onto anything. >> >> scoped_session OTOH is nothing more than a thread local variable. >> Background on this concept is available here: >> http://docs.python.org/library/threading.html#threading.local . The >> remove() call removes the current thread local's context. If your app were >> single threaded, you could replace it with a single Session object, where >> you just call close() instead of remove() - it wouldn't be very different. >> >> Within the context of a multiprocess, single-threaded application, >> threading.local doesn't have any effect - there's just one thread. >> >>> Importantly.. I can completely close all my processes and cold start my >>> code - and this error continues until I restart mySQL ! i.e. NO session >>> will work again, but I can do basic queries. What the?! >> >> I've seen this happen with PG when we are testing out two-phase >> transactions. You might want to ask on some MySQL forums what queries you >> might do to look at current lock/transaction state. >> >>> >>> BTW: It someone says "You should be using scoped_session.." Please explain >>> how to have either more than one session in the same context (I use three >>> for a possible three different binds) >> >> yeah I actually have an app with a couple of scoped sessions, since there >> are two different databases and operations generally proceed with one or the >> other. >> >>> or how to create one session that I can bind to more than one engine, and >>> not have to know in advance all possible tables I might want to use on each >>> engine.. >> >> If the table metadata is bound to an engine, then the session doesn't need >> to be bound. I.e. if tables A, B, C on metadata X are bound to engine P, >> tables D, E, F on metadata Y are bound to engine Q, you just use the >> Session, and it will handle the two engines as needed. >> >> If you really want total control, using some ruleset that's not quite as >> simple as table->metadata->engine, you can subclass Session and override >> get_bind(). I've never recommended that to anyone, but I put it out there >> just to help de-mystify the situation. Its just one call that takes in a >> mapper, returns an engine. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To post to this group, send email to sqlalch...@googlegroups.com. >> To unsubscribe from this group, send email to >> sqlalchemy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sqlalchemy?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
