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 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.
