Fernando Takai wrote: > Hi!, > > I'm using SQLAlchemy on a heavily threaded env - something like 30~40 > threads working with SQLAlchemy objects. > What you need to watchout is: > > * Eager load objects - getting nasty lazyload exceptions is not funny > * Take off the objects from the session and, if you need to use them > later, merge to the current thread session - i did this because i had > some "object-is-already-on-session-foobar" exception > * Don't forget to use scoped_session > > Beside those two points, working with threaded apps is quite easy with > SQLAlchemy. :)
even the "eager" advice above has nothing to do with threads. that has to do with using your objects after your session has been closed. if you think of your objects as "agents" of your current database transaction, and as a "detached" object as a something that really needs to be re-attached to a transaction somewhere so that it can become an "agent" once again, no such issues occur. > > On Fri, Mar 26, 2010 at 10:12 AM, Matthew Williams <mgwilli...@gmail.com> > wrote: >> Thank you, Simon, for clarifying this and pointing out that part of the >> SQLAlchemy docs... somehow I missed that part :-). >> >> On Mar 26, 2010, at 7:30 AM, King Simon-NFHD78 wrote: >> >>> I think that point should be clarified, so that people don't later come >>> across this post and just accept it without understanding. >>> >>> I imagine that SQLALchemy is used in a lot of threaded applications. >>> For >>> example, it is the recommended ORM in web frameworks such as Pylons and >>> TurboGears, which work fine in threaded environments. However, >>> typically >>> in these libraries a web request is handled by a single thread, and all >>> the SQLAlchemy operations occur within the scope of that request. As >>> long as you don't share a Session instance between the threads, you >>> won't have any problems. SQLAlchemy provides a ScopedSession class >>> which >>> helps in these situations, as you can call the constructor many times >>> on >>> a single thread and always get the session instance back for that >>> thread. Sessions themselves aren't thread-safe. >>> >>> When an instance is loaded from the database, it is linked to the >>> session that loaded it. This means that when you have lazy-loading >>> properties on that instance (such as related classes, or deferred >>> column >>> properties), they will be automatically loaded when they are accessed, >>> in the same session. >>> >>> This will cause a problem if you load an instance in thread A, hand the >>> object off to thread B, and then thread B accesses one of these >>> lazy-loading properties. The load will occur in thread A's session, >>> which might be in the middle of doing something else. >>> >>> The solution to this is either to eager-load all the attributes you >>> think you are going to need before handing the instance off to another >>> thread (difficult), or (probably better) to detach (expunge) the >>> instance from thread A's session. Thread B should then merge the object >>> into its own session (using the load=False flag so that it doesn't >>> needlessly requery the database). >>> >>> The Session docs at http://www.sqlalchemy.org/docs/session.html explain >>> the lifecycle of loaded instances. >>> >>> I haven't actually done any of this - I've only ever used SA from TG >>> and >>> command-line scripts, but I think the principles are about right. I >>> hope >>> that helps, >>> >>> Simon >> >> -- >> 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. >> >> > > > > -- > Fernando Takai > > -- > 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.
