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. 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? 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.
