Hello, Thank you very much for your reply!
Each thread gets its own session. The first thread, after adding a User object, appends its primary key into a global List. The other thread which is trying to modify the object : - Pops an id from the global list - Queries the object from the DB using its own session using the id popped. This query adds the object to the second threads session, right? >>> Sharing the object across threads works against the transaction model which you are trying to take advantage of. Your second thread is in its own transaction, and should be loading all of its information from that transaction. By hitting user.UserID in the second thread, you're attempting to access database data from the original transaction which "user" is still associated with and concurrency related issues are occuring. >>> The first thread is trying to put the UserID into the gloabl list (this way, it passes the id of object it just added to the second thread). So, in the line where it is trying to USERIDLIST.append(user.userid) in the first thread. When expire_on_commit is set to True, this statement issues an internal query, and I get this exception. PS : I add around 100 users in the thread, and the below exception occurs randomly during the addition. Any inputs? Thank you so much again! On Mon, Aug 25, 2008 at 8:12 PM, Michael Bayer <[EMAIL PROTECTED]>wrote: > > On Aug 25, 2008, at 12:24 AM, Harish K Vishwanath wrote: > > > > The line USERIDLIST.append(user.UserID),is trying to append the newly > added (to the database) user object's primary key (UserID) into a List in > one thread , to be used by another thread which tries to modify the object. > Its throwing up exceptions there. > > This error will go away if I set expire_on_commit = False. > > > From all indications, this is concurrent Session access which is not > supported - any object which is associated with a Session can call upon its > owning Session at any time. > > Sharing the object across threads works against the transaction model which > you are trying to take advantage of. Your second thread is in its own > transaction, and should be loading all of its information from that > transaction. By hitting user.UserID in the second thread, you're attempting > to access database data from the original transaction which "user" is still > associated with and concurrency related issues are occuring. > > Approaches to fix include: > > 1. The easiest way to do this is to keep all objects local to one thread. > 2. Instead of passing "user" to the other thread, pass only user.UserID to > the other thread. This keeps the access to "user" within its owning thread. > 3. expunge() your User object from the thread in which it was created, and > add() it to the Session corresponding to the other thread, before accessing > user.UserID > 4. merge() your User object to the Session corresponding to the other > thread, where a copy of it will be created local to that Session (would have > to see if merge() is smart enough to not load in expired attributes, > though). > 5. use mutexing to prevent concurrent access to the first Session (this may > also necessitate not using ScopedSession depending on usage patterns). > > > > > -- Regards, Harish --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
