On Aug 12, 2010, at 11:47 AM, Faheem Mitha wrote: > On Thu, 12 Aug 2010 09:44:04 -0400, Michael Bayer <mike...@zzzcomputing.com> > wrote: >> >> On Aug 12, 2010, at 9:25 AM, Faheem Mitha wrote: >> >>> >>> Hi Mike, >>> >>> Thanks for the response, but I don't follow. >>> >>> When you say "multiple threads are hitting the session you have >>> above", which session are you referring to? There is more than one >>> object above that could be called a session. Ie. >> > >> I don't actually know, it would require that I have a full install > of your application for me to run and step through with a debugger > to fully understand what it's doing. All I can say from here is > that the errors you have suggest concurrent access to a single > psycopg2 connection resource, and that a single Session references a > single connection when in use. A MetaData object does not, nor does > an Engine - only a Session. If you remove all threading from your > application and the errors go away, then you know you're accessing > some resource illegally. > > Yes, I see. Yes, the error does not show up unless I run multiple > threads, and I agree with your interpretation. > > If MetaData is threadsafe, then using ThreadLocalMetaData is not > necessary?
ThreadLocalMetaData is not necessary and is not used for this purpose. > > Ok. Thanks for the confirmation. So, if I was to use scoped sessions > systematically everywhere, this problem would likely disappear. that's not necessarily true - if you share individual persistent objects among threads, they reference their owning session in order to load additional state. If you pass objects between threads you should merge() them into the current thread's session first, then use that result. > Can > you confirm that there is no reason not to use scoped sessions > everywhere, even in serial execution? Of course, if that is the case, > then I wonder why non-scoped sessions are used at all. scoped_sessions are usually the default choice for web applications since they desire distinct transactions and object state for individual threads. They are overkill and potentially confusing or inappropriate in other situations, however. -- 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.
