On May 28, 2008, at 7:09 PM, Laurence Rowe wrote:
Engine configuration is a subset of session configuration. You
cannot have a single ScopedSession for a package if you want to have
multiple instances of that application. We must work with unbound
metadata if we have this goal. That implies that we must use bound
sessions, a session associated with a particular engine (actually it
could be more complex than this, you can associate particular
classes/tables with particular engines within a session).
<chiming in, although I haven't read the whole thread....>
I would agree that "bound" metadata is a little cumbersome in an
environment that wants to switch engines within a single process.
"Bound" metadata has always given us a lot of headaches because it's
just *so* convenient that we just can't get rid of it, but at the same
time people are just so tripped up by it, thinking it's necessary to
make anything happen (it's not). Binding sessions allows better
control of connection/transaction scope (since the Session relates to
transactions, MetaData does not), so it's probabably the way to go in
an environment that has a lot of things going on.
As far as ScopedSession, it's really just a thread local variable.
Like any global threadlocal, you can stick whatever you want on it at
the start of a request, and tear it down at the end. Then again it's
also reasonable that you might want to have individual ScopedSessions
for each application instance within a multi-app process, that way the
burden of setting up/tearing down is reduced or removed. A single
ScopedSession for a multi-app process is like a one-dimensional
approach where both current thread and current app are identified by
the current "get()" of the registry; a collection of ScopedSessions is
more like a two-dimensional approach where the first level of registry
(i.e. which ScopedSession do I choose) distinguishes between app
instance, and the second level (i.e. what Session is bound to this
thread ID) distinguishes between threads.
All of that said I think it can work either way but I think the latter
approach might have the explicitness you're looking for.
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
