On Sep 22, 2011, at 5:04 AM, Ben Ford wrote: > Hi Mike, > > It is an edge case for sure. I'm using SA with eventlet so the session is > going out of scope in a green thread. Eventlet does some monkeying > (literally) around with threadlocals so I get a different session for each > one. However in this case the parent instance to which I'm adding obj was > fetched in a one greenthread and the child is added in another after a timer > has fired off (the child is a record of the timer running). It's definitely > fair to say that I'm not using SA in an optimal way, however I'd still be > inclined to say that the patch could be worthwhile here.
I'm going to do the patch since that's how I'd like it to work, but that is the least of your problems here, if you're linking the scope of your sessions to a library that is repurposing threading to be a system of supplying ad-hoc, transitory context to a longer series of operations. There's nothing wrong with that approach from a threading point of view, but with this repurposing, it's no longer appropriate to link an operation-scoped object like Session to a thread. You need to use a contextual callable with scoped_session() that links the lifespan of a Session to the lifespan of the series of objects you're working with - it accepts an argument "scopefunc" - this is a function that should return a "key", usually a string but can be anything hashable, that represents "this is the current context". For example, if the function was threading.get_ident(), you'd get thread local behavior. I usually use what I call the "dinner party metaphor" here, the set of objects you're dealing with is your meal, the Session is the plate. You don't want to keep switching plates for every bite, chucking the previous plate onto the floor with whatever is still stuck to it. You want to receive your plate, finish your meal, then return the plate. The thread is usually the dinner guest here but your guest is busy performing on stage, so you need to invite a new guest who knows how to dine properly. The Session is linked to an ongoing transaction in the database, unless you've turned that off with autocommit=True, and your app should be able to keep track of such a concept, even if eventlet is switching around threads underneath. If this is going to go the other way, where none of that is possible, then you should be disabling most of Session's automation, turning on autocommit, turning off expire_on_commit, turning off autoflush. Randomly switching sessions among any subset of objects in a connected graph is generally going to create havoc in any case though. > > > Is there any particular reason that you added the check where you did in the > patch as opposed to the except KeyError clause in _state_session? The _attach() method of Session, the point at which we determine if an owning Session still exists, doesn't call _state_session(). If you mean why don't we call _state_session() there for the purposes of encapsulation of the session_id attribute, that would imply the whole middle of _attach() just calls _state_session(), which introduces additional function call overhead in a fairly critical section. _attach() needs to be aware of session_id in any case so it's IMHO fine that it interprets this attribute fully. SQLAlchemy's code is necessarily inlined in many places due to Python's tremendous function call overhead, some background on that (skip down to the second section, the first half is just wanking) is at http://techspot.zzzeek.org/2010/12/12/a-tale-of-three-profiles/ . -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
