Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jc.textor@gmx.de designates
 213.165.64.20 as permitted sender)
Message-ID: <42EF6247.3070300@gmx.de>
Date: Tue, 02 Aug 2005 14:08:39 +0200
From: Johannes Textor <jc.textor@gmx.de>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: AW: AW: Accessing the cocoon session from my Hibernate User-Type
References: 
 <4202DDA3828BD24D9381128D46B13D2B024FEF77@ktaemail01.villa-bosch.de>
In-Reply-To: 
 <4202DDA3828BD24D9381128D46B13D2B024FEF77@ktaemail01.villa-bosch.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 it.
>  
>
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 flowscript:

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 thread.

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.

Regards,
Johannes


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org