On Apr 9, 2007, at 12:47 AM, David Bolen wrote:
> > The Session object clearly isn't thread-safe, which is fine, but I was > curious if the intention is for that to also include its initial > allocation? > > That is, I'd like to potentially allocate a new Session object in > thread A, but any and all operations on the object aside from the > instantiation would be from thread B. So never more than one (and > always the same one) thread using the Session instance, but it's a > different thread than the one that initially allocated it. > no problem at all with this. thread local behavior doesnt enter into the equation unless you are using the SessionContext extension. operations on Session can be spread among any number of threads, just that its operations arent synchronized. one thing to keep in mind is that objects which are bound to that session will in many cases have modifying behavior upon their owning session, such as a lazy-loading attribute or cascading operations. so your domain objects also have to be treated gingerly with regards to threads. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
