__before__ and instance variables

[ozwyzard]

I am using TG 2.0.4.  Till now I used to save the user_id in the __before__ method of a controller and use it later in an exposed method of the same controller.  During testing, I came across a scenario (race condition) where the self.user_id is not what I expected inside foo().  It seems that self.user_id is overwritten by request2 when I am processing request1 in parallel.  All along I thought that the values stored in the controller self variable are request specific.  I figure my understanding is wrong.   Can someone confirm!

If I want to store request specific information to be used later in the processing, should I store it in the request object itself?  Or maybe create a req_context object and store all the needed information, and add the req_context object to the request.

Any other suggestions welcome.


Thanks

   def __before__(self, *args, **kw):
        tmpl_context.menu_items = self.menu_items
        tmpl_context.title = title
        identity = request.environ.get('repoze.who.identity')
        self.user_id = identity['user'].user_id
        self.user_name = identity['user'].user_name

@expose()
def foo(self):
     # use self.user_id for some operation

http://turbogears.org/2.0/docs/modules/tgcontroller.html

__before__(*args, **kw)

Override this method to define any action you would like taken before the controller code is executed. This is particularly useful for defining a Controller-wide specification (all methods) for things like: setting up variables/objects in the template context, restricting access, or other tasks which should be executed before the controller method is called.

[Alessandro Molina]

You can store request specific objects inside the request itself or
inside the tmpl_context object.
Writing controller instance properties can lead to race conditions.

Keep in mind that you already have the user_id always accessible
anyway, request.identity['user'].user_id should retrieve it inside
controllers.

> __before__(*args, **kw)Override this method to define any action you would

> like taken before the controller code is executed. This is particularly
> useful for defining a Controller-wide specification (all methods) for things
> like: setting up variables/objects in the template context, restricting
> access, or other tasks which should be executed before the controller method
> is called.
>

> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/turbogears/-/5M8HCqCL0cEJ.
> To post to this group, send email to turbo...@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears?hl=en.

[ozwyzard]

Thanks for confirming that it would lead to race conditions.  Agree that one can store request context variables in request or tmpl_context.  Thank you!

[ozwyzard]

I have the need to store a few other related variables and derived variables.  I will store them as attrs of "c" in the __before__ method (where c is "from tg import tmpl_context as c"), and use them in the controller methods.  Thanks.

[Alessandro Molina]

On Tue, Sep 4, 2012 at 4:28 AM, ozwyzard <ozwy...@gmail.com> wrote:
> Thanks for confirming that it would lead to race conditions. Agree that one
> can store request context variables in request or tmpl_context. Thank you!
>

It actually depends on the TG version as some reuse the controller
instance for multiple requests,
for that reason relying on the ability of storing controller
properties is not suggested.

[ozwyzard]

Thank you.  Is there some document that would talk a few points on context, threads, (locking issues if any), etc.  Or does one have to read the dispatcher code?  Sometimes documents are a context-switch for the brain.  If there are any detailed notes in the code or README_DESIGN.txt in a separate file, let me know.  I have the pylons book, but do not recollect it going into such detail.  Thanks again.  Congratulations on TG 2.2!

[ozwyzard]

What I meant was, "writing" documents are a context-switch from coding, so if there are detailed design notes in the code, let me know.  Thanks.

[Alessandro Molina]

Sorry, I was not saying that it changed during the last release, so
currently there isn't any changelog you can look at for informations
about that.

More generally speaking controller instances should be considered an
internal implementation detail and how they are stored and reused can
vary any time for performance reasons, while tg.tmpl_context and
tg.request are actually meant for storing request related variables
and will always behave properly for that use case.

That is the reason why I'm suggesting you to avoid storing request
related variables inside the controller, unless you created the
controller yourself during the request life cycle (for example inside
a _lookup) as in that case the controller instance relies only to the
thread the is handling the request for sure.

> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/turbogears/-/Ca3e1UkprxsJ.

[ozwyzard]

Understood.  I realize it is much further out, but since we are on topic, if TG 2.5 or later were to adopt pyramid (which preserves tmpl_context only as a backward compat), I suppose TG will provide an equivalent of the current tmpl_context.