Thanks Johannes for the needed remarks ! I have already implemented it and it works quite well. Now for some testing with multi users...
Elad -----Ursprüngliche Nachricht----- Von: Johannes Textor [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 2. August 2005 14:09 An: users@cocoon.apache.org 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
