Emmanouil,
such a document would be of great help, for those issues have not yet been widely investigated AFAIK.
As long as configurations are accessed in a read only manner, they should be shareable between different threads. This is true for all configuration implementations that inherit from BaseConfiguration because these are based on a HashMap. For hierarchical configurations like XMLConfiguration I did not check this explicitely, but I am quite sure that they are thread safe because no internal state is modified when properties are read.
So best practices for read only configs is probably to load a central instance during application initialization phase and provide access to it to all interested components (e.g. by storing it in the app context).
If configurations are modified, thread safety is not guaranteed. Maybe a useful extension for the future would be a synchronized configuration wrapper similar to the ones used by the Java collection framework. How to handle this kind of configurations will strongly depend on your application's needs, e.g. which components change data, where are changed configurations written back, etc.
Note that the above is not a result of a detailed analysis. There may be some details that make the whole stuff more complicated. E.g. I am not sure how the new reloading features affect thread safety.
HTH Oliver
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
