Very good info on the execution details, thanks for putting that
together, super helpful.

I posted over on the mongodb-user group and the developer of pymongo
stated that it should be ok to share the global connection across
threads.  I suppose that means it is thread-safe, although it was not
explicitly stated such.
http://groups.google.com/group/mongodb-user/browse_thread/thread/9e98b2c41845c9da

Thanks for yall's help.


On Sep 16, 12:31 am, Mike Orr <[email protected]> wrote:
> On Tue, Sep 15, 2009 at 5:23 PM, Hans Lellelid <[email protected]> wrote:
> >>> does pylons guarantee a
> >>> new instance of your controller object for handling every request (and
> >>> hence, per thread)?
>
> >> I think that is a key question ... so I searched around a bit more - I
> >> found this (see Mike Orr's post)
>
> >http://groups.google.com/group/paste-users/browse_thread/thread/bcf2e...
> >> ""... Pylons assumes its native controllers are not thread
> >> safe, and instantiates one for each request. ...""
>
> >> So, from that I assume Pylons instantiates a new controller instance
> >> per request.
>
> Yes.
>
> >> I guess, my next step is to determing in pymongo's connection is
> >> thread safe or if I need to use thread local.
>
> >> (I've been looking at sqlalchemy/pylons code to figure out how they do
> >> threading and whatnot with the model, but for the uninitiated it can
> >> be a little confusing if you don't know what you're looking for.)
>
> > Yeah, I concur.  Frankly, the Paste internals are really hard to follow,
> > and SQLAlchemy is not much simpler.  Paste adds additional complexity by
> > using the StackedObjectProxy, which is more than simply a thread local.
>
> The PylonsExecutionAnalysis goes through it step by 
> step.http://wiki.pylonshq.com/display/pylonscookbook/Pylons+Execution+Anal...
>
> There are other dimensions besides threads.  For instance, two Pylons
> applications, or two instances of the same application, mounted under
> different URL prefixes in the same process.  StackedObjectProxy
> handles both the thread dimension and the application dimension.
>
> I don't know MongoDB, but most database connections are not thread
> safe, and SQLAlchemy sessions are not either.  The ``meta.Session``
> object in the default Pylons/SQLAlchemy configuration is a scoped
> session, meaning it's automatically thread-local.  We're not sure if
> it's safe with multiple application instances in the same process, but
> there are rare and nobody has complained.  You could put it on
> ``pylons.app_globals`` to be extra safe, but that makes the model
> dependent on the rest of the application.
>
> You can put a connection in ``self`` or ``pylons.c`` and it will be
> local to the request.  You can do this in the base controller's
> .__before__ or .__call__ .  This would create a connection for every
> request.
>
> If that's too much overhead, you can put a threadlocal object on
> ``pylons.app_globals``, but you would have to create the threadlocal
> yourself.  There's a threadlocal constructor somewhere in the Python
> stdlib.  And you would have to create the connection if it doesn't
> exist (i.e., if this is the first request for the thread).
>
> --
> Mike Orr <[email protected]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" 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/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to