Diez, Just so that I am reading you (and this thread) clearly here about controller instantiation... all controller classes are instantiated as objects on a per request basis.. yes? Therefore, if I have a sub controller with an __init__ that does some work needed, common to all my controller class methods, it can assign local (self) attributes in a thread/request safe way, yes? I was just looking at the docs at: http://www.turbogears.org/2.1/docs/main/TGControllers.html and from the docs it looks like this is the case (as I describe). Specifically, I'm looking at the calling conventions for the _lookup method as my indication for this.
John On Mar 17, 5:33 pm, "Diez B. Roggisch" <[email protected]> wrote: > Hi, > > > When running a tg2 app with "paster serve", I was expecting controller > > objects to be instantiated once per worker thread. > > I've even been surprised by them being instantiated more than once per > process. > > But it's not as bad as it looks. > > > > > However, when I add logging to BaseController.__init__, it seems that > > the full hierarchy of controller objects is instantiated once per > > request. > > > E.g. when I exercised my app with ab -c 100 -n 1000 (100 concurrent > > clients making 1000 requests, total) the controller objects were > > instantiated 1000 times... > > No. The *root* controller is instantiated as often as that. But > clearly all sub-controllers ar class-attributes, thus they aren't > instantiated more than once per process. > > Is that wierd? Certainly. If you insist, just make the root-controller > a singleton. But I doubt the instantiation overhead of that one object > really matters (unless the __init__-method does soemthing, which none > of our controllers does, as they are not supposed to hold any state > whatsoever). > > What you won't get under no circumstances though is a per-thread- > instantiation, unless you code it yourself of course. > > > > > Is that the expected behaviour with paster serve? Does anyone know if > > mod_wsgi, for example, is different? > > No, it isn't. It takes the same WSGI app entry point. Whatever happens > with the controllers is subject to the routes/object-dispatch code. > > > > > The reason I ask is that I need (non-DB) connections in my controller > > methods which are fairly expensive to create. If controller > > instantiation is once per thread, I'll need to create a connection > > pool, populate it at startup and manage it over time; is there a best > > practice for this? > > I don't fully understand what you are after here. Do you actially want > a pool of connections, per thread? Then you need to manage that > yourself, yes. > > But it's easy enough. Just create a threadlocal attribute, either at > module-level, or controller-level, or wherever you like. When it's not > set in the current thread, instantiate a connection. Use the existing > one otherwise. > > Diez -- You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en.
