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!

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.

Reply via email to