commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Catalin Grigoroscuta <c.grigorosc...@moodmedia.ro>
Subject Re: [Configuration] thread safety and performance in enterprize apps
Date Tue, 29 Mar 2005 11:58:30 GMT
Hi,

I want to point out that option 2 (instance per thread) is not really an 
option is a J2EE app.
J2EE is a container managed environment, when the threads are managed by 
the container, and is not a good idea to put ThreadLocalS on these threads.
I've recently spent quite a few days debugging memory leaks in web 
applications that occured when you stop/start the application. The 
problems were caused exactly by "forgotten" thread locals, which kept 
strong references to classes that would otherwise be garbage collected 
(actually, the memory leak is quite big, as the whole app is kept in 
memory because a strong ref to the class loader is kept through thread 
locals).
The base line is: be very careful when using thread locals in 
container-managed applications, and never let such a thread local "live" 
at the end of a request.

Emmanouil Batsis wrote:

>
> Hi all,
>
> I was wondering if the list members can help me pin down best 
> practices regarding use of Configuration in J2EE apps:
>
> * For read-only XML configurations, how does performance differ between:
>       - sharing the same instance (via in the application context or 
> JNDI) globally (which classes are better for that?)
>       - use one instance per thread/request (threadlocal)
>       - instantiate configuration objects "locally"
>
> * How does the above work for read-write configurations?
>
> I'd happily compose a document based on given input (even xdoc, as i 
> need to learn that too ;-).
>
> Many thanks,
>
> Manos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message