On May 20, 2011, at 4:12 PM, Adrian wrote: > So if it is the latter, that the Session is being shared amongst > threads, what is the correct way to handle the sessions from within > Turbogears? What I do now is create a scoped_session in the model, and > import it into each controller. For a while, I made use of special > functions _before() and _after() to create the session in _before the > page loads, and close it in _after, but then I was getting > DetatchedInstanceErrors when I tried to access columns from objects > returned to the template. > > I'm not sure how familiar you are with Turbogears, so I apologize if > this is too much of a TG question...but I asked this on their mailing > list and their answer was that what I was doing was correct -- > obviously it's not if I'm getting these AssertionErrors... > > Thanks for the quick reply, as usual!
So scoped_session() will ensure that sessions are associated with threads. Its not a total guarantee of thread safety if for example you're placing objects in some kind of in-memory cache, then using them in other threads without detaching them first from their original session. You really need to figure out what the catalyst for the issue was - short of locating the actual cause of the bug, that would produce the most clues towards what it is. Or, this is a really harsh approach that I had to do once when a deeply nested call to a defunct Google service started crashing the site, I had to disable all pages on the site, then slowly turn one page on after the next to isolate which one was the cause of the issue. Clearly that isn't an option in lots of cases but it depends on if you can reproduce the issue locally, perhaps when load testing with Apache "ab" and such. If its something I had seen before that would help but I've never seen anyone hitting that assertion before. > > On May 20, 9:59 am, Michael Bayer <mike...@zzzcomputing.com> wrote: >> On May 20, 2011, at 9:45 AM, Adrian wrote: >> >> >> >> >> >>> I have a Turbogears server that uses sqlalchemy to interface with a >>> postgres database. Today, I noticed the server was down, so I tried >>> restarting it. Now my turbogears log is full of errors like: >>> AssertionError: A conflicting state is already present in the identity >>> map for key (<class 'dr8db.ModelClasses.FITSHeaderKeyword'>, (1045,)) >>> and >>> Exception KeyError: KeyError((<class >>> 'dr8db.ModelClasses.MaskbitsType'>, (61,)),) in <bound method >>> InstanceState._cleanup of <sqlalchemy.orm.state.InstanceState object >>> at 0x4445c90>> ignored >> >>> I tried googling this stuff, but found nothing... >> >>> Basically it lets me start the paster (Turbogears) server, but after >>> ~5-10 minutes the server dies and there are hundreds of these errors >>> in the log -- help!! I need to get this server back up ASAP! >> >> That's an assertion that is generally unreachable from within the Session. >> The only ways I think you could get there would be via direct manipulation >> of session.identity_map, or if the Session is being shared among concurrent >> threads, which is not supported. >> >> The main thing you'd be looking for here is, at what point did this server >> begin to fail and what event precluded that happening ? Either a code >> update, or perhaps the app was never tested against its current load, are >> the two possibilities. > > -- > 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 > 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 sqlalchemy@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.
