tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <>
Subject RE: ThreadLocal relationship to servlet requets and use to store variables
Date Thu, 30 Oct 2003 14:05:06 GMT

ThreadLocal is risky.  

This is the type of situation where the servlet 2.4 request listeners
might be useful: you'd create you session-like object when the request
is initialized, use it etc, and then destroy it when the request is
done.  That object would be a Map-type structure, decoupled from the
servlet API ;)

Yoav Shapira
Millennium ChemInformatics

>-----Original Message-----
>From: Christopher Schultz []
>Sent: Thursday, October 30, 2003 7:55 AM
>To: Tomcat Users List
>Subject: Re: ThreadLocal relationship to servlet requets and use to
> > Unfortunately, the corporate architects do not allow
>> presentation tier (ie: servlet requests) to be passed all the way
>> to the persistence tier.
>This is a good policy. Your persistence should have nothing to do with
>your presentation.
>> The goal is to put the session pull the login
>> id out of the servlet session, on each request, and stick it in an
>> application defined session object instance that is uncoupled from
>> servlet api's.
>Why not pass that application-session object to your "session"-based
>services, instead of playing tricks with ThreadLocal.
>> Putting the Session instance into thread local would, I
>> hope, make it available to the persistence tier without adding a
>> parameter all the way through all method calls top to bottom.
>Yes, ThreadLocal will do that, but it's very messy, pretty much
>impossible to document, and probably just not the right thing to do.
>You don't necessarily need to add parameters all the way down the call
>tree. Did you guys design a persistence layer with methods that take no
>arguments? That sounds weird... why can you not use the intended
>in your persistence layer?
>To unsubscribe, e-mail:
>For additional commands, e-mail:

This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.

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

View raw message