On Jan 17, 2012, at 9:03 AM, John Hufnagle wrote:
Didn't see an answer to this in the discussions.
I have:
1. slqlchemy 0.7.3, cherrypy and mysql Ver 14.14 Distrib 5.5.18, for
osx10.6
2. a cherry py application that initializes the scoped session as:
Session = scoped_session(sessionmaker(bind=engine))
3a. Passes that Session instance into a background worker thread.
3b. Passes that Session instance into the Request processing objects
that handle the http requests.
right off, I think it's important here to understand what scoped_session means.
The scoped_session is only a *registry* that stores sessions, it's not a
Session object itself. When you first call upon it, that is, Session(),
*then* you get at an actual Session object, keyed to the current thread. If
you call methods on the scoped_session object itself, those are proxied into
the Session that's local tot he current thread.
4. in the run() method of that background thread (3a) it issues:
session_obj = passed_in_session_object() # passed_in_session_object
came in from the main from step 3a.
#this session_obj is used for SELECT's against the db
wakes up every minute and does SELECTS to see if the http handler from
5 (below) has written any objects to the db.
So it's not clear here at what point you deal with Session and at what point
you deal with the actual Session object returned by Session(). If you're
passing actual Session objects between threads (which is not really recommended
unless you're really sure of what you're doing) you'd need to make sure its the
Session object, not the scoped_session registry.
Overall I would refrain from passing Session anywhere, the recommended usage
of scoped_session is as a module level global that's accessed as needed in a
thread-local fashion. I'm not sure what your gaining by passing sessions
between threads. Each Session has its own transaction going on, and as long
as those transactions remain open they won't see any changes that have occurred
since the transaction is opened (note that transactions are typically isolated
from seeing concurrent changes elsewhere).
It's not like you can't pass sessions between threads and such but that's an
advanced technique where you'd need to be very aware of which sessions have
what transactional state going on. Hence the scoped_session as a global,
threadlocal registry, where all threads consult it, open a session, do their
work, then close it, and that's it, is the default model, being the easiest
to understand.
--
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.
