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
|