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. :) 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.
