On Tue, Jul 29, 2008 at 10:06 PM, Olaf Conradi <[EMAIL PROTECTED]> wrote: > Cool, I'll try when I get home from work. Thanks. > > There is another difference though. > The only global definition I have is the StackedObjectProxy (SOP) > called storm_session. > > I instantiate ZStorm() in the middleware layer and register that to > the storm_session SOP. > > Which will create one ZStorm instance per request and the module using > it does not need to know which one. > This helps when multiple wsgi apps run in the same process.
Creating one ZStorm instance per request would mean that you're creating one database connection per request. One of the main purposes of the ZStorm singleton is to manage a set of per-thread stores so that a web app that serves requests from a thread pool will have a fixed number of long lived database connections that get reused. If you are creating a ZStorm instance for every request, then you could remove all the threading.local() usage. If you are two independent apps colocated in the same process, you have two options: 1. if they are connecting to the same database, then let them share the same store by passing the same store name to get() 2. if they are connecting to different databases or the same database with different settings, use different stores with different names. In both cases, the database URIs can be configured once at startup with global_zstorm.set_default_uri(). James. -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
