cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Messing, Elad" <>
Subject AW: AW: AW: Accessing the cocoon session from my Hibernate User-Type
Date Tue, 02 Aug 2005 13:27:40 GMT
Thanks Johannes for the needed remarks !
I have already implemented it and it works quite well. Now for some testing with multi users...


-----Urspr√ľngliche Nachricht-----
Von: Johannes Textor [] 
Gesendet: Dienstag, 2. August 2005 14:09
Betreff: Re: AW: AW: Accessing the cocoon session from my Hibernate User-Type

Hi Elad,

>	I actually came to the same conclusion myself, when waiting to your reply and doing some
googling :). 
well that should mean it's not such a bad idea I hope :) 

>	However I have used the ThreadLocal object. I didn't quite understand the differences
between the Inherited and the ThreadLocal, and when I should use each... I will try to research
InheritableThreadLocals are passed on to any child threads created by the current thread.
This might be necessary because cocoon could spawn up new child threads, for example in a

cocoon.sendPage( .... )

is an asynchronous call, so I'd say it spawns up a new thread (without actually having checked
the source).
So your User object would be invisible to the pipeline created by cocoon.sendPage( ... ) when
it is stored as a ThreadLocal. Using an InheritableThreadLocal OTOH, the child thread would
receive its own copy of the User object.

>	Another thought I had is regarding what and when to store in the ThreadLocal.
>	What - I am not sure I should store the whole user request. I mean - If I only need the
locale, why store the whole request ?
You're right, it should suffice to store the Locale. I stored the entire request for 2 reasons:

1.) At present, I'm using an OpenSessionInView filter to manage the Hibernate Session. Communication
between the filter and cocoon takes place via the request object. By storing the request object
in the ThreadLocal, the HibernateSession becomes also accessible to all objects, which makes
it unnecessary to pass the Session instance as a parameter to DAO Objects (which, in fact,
breaks the DAO Design pattern).

2.) There is a subtile issue here with the InheritableThreadLocal. Upon creation, the child
threads receives a copy of all of the parents InheritableThreadLocal objects. But after this
point, if the InheritableThreadLocal is changed by either the parent or the child, changes
are not reflected back to the other.

For instance, in the cocoon.sendPage example, the pipeline invoked might want to change the
user locale - but this change would be invisible to the flow script which lives in the parent

Storing a reference to the request object in the ThreadLocal is a
(brutal) way around this problem: The
reference itself is never changed, only the values inside the request object. These changes
will then be visible to all possibly created child threads.

However, storing the Locale in a Map or Hashtable which is then stored as an InheritableThreadLocal
would yield the same effect.

>	When - I thought about using the locale action - which already is 
>in-charge of locale maintaining, to save the locale in the 
>ThreadLocale. I thought about inherit it, and add the needed code 
>(User.setLocale( locale ); )
Sounds like a good idea.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message