On Nov 28, 2008, at 1:42 AM, Harish Vishwanath wrote: > > I am guarding my commits with a mutex,
if you are using one session per thread then there is no need to use mutexing. > > but the queries are unguarded. if you are using a single Query object in multiple threads simultaneously, that will be problematic, since their usage, as well as usage of the objects produced by the Query, constitutes session access, as in when rows are loaded. Especially if autoflush is turned on then you'd essentially be using the Session in a completely thread-unsafe manner. > If one of the session is committing on the database and the other > one is trying to query, would this problem arise? there is no issue with this as long as all Session, Query and persistent instance is maintained local to a single thread. Issues at the level of concurrent transaction contention are handled by the database (and this error is not related to that). > I am not very sure on how connection objects are created during this > scenario. Appreciate your help. The Session typically references a single database connection throughout the lifespan of a transaction. when the transaction completes, the connection is returned to the pool. The actual transaction state of the Session is determined by the configuration flag "autocommit=False" as well as the begin()/commit() methods. These are described in the docs. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
