[This message has also been posted.]
On Thu, 12 Aug 2010 12:47:37 -0400, Michael Bayer <mike...@zzzcomputing.com>
wrote:
>
> 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.
I see. That's very enlightening. Can one query such objects to
determine their owning session? Some attribute, perhaps?
>> 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.
I'm not sure why they would be potentially confusing. What are some of
the downsides? I'd have thought that not having shared state was less
confusing.
Regards, Faheem.
--
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.
