Wouldn't it be possible to create a thread-safe modification method that locks the underlying structures during modification? I don't think you need to ensure thread safety on the read operation, just the modification operation...
You yourself said no locks are needed during read time when you know the configuration won't change, and I assume that's the mechanism by which you assure the performance aspects, by simply not synchronizing during read... If that's the case, I would think simply synchronizing in the modification method would allow you to still have the performance while introducing the ability to safely modify the configuration.
Granted, that introduces a bottleneck because every request would have to wait until any modification is complete, but I would consider it the pervue of the app developer to decide if that's a problem or not (and make sure it isn't through reasonable usage of the ability and proper app architecture around it).
I guess the question I should ask is when you say the configuration "is frozen", is anything really done to make it read-only? Or is it simply the case that one COULD right now modify the configuration if they are willing to forgo thread safety?
Just a thought anyway (and completely uninformed I admit because I haven't taken the time to look at any source to see what's currently done)...
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Craig McClanahan wrote:
On Thu, 16 Dec 2004 11:21:01 -0500, Chaikin, Yaakov Y. <[EMAIL PROTECTED]> wrote:
Craig,
What is the reason the configuration gets "frozen"? I don't mean to ask about the mechanics of how it's frozen. I am just curious as to why freeze it and not let it be dynamically updated during application lifetime?
The primary reason for this approach is a performance-related optimization.
Underlying most of the collections of configuration objects in Struts are uses of HashMap, which is explicitly declared to be non-thread-safe for methods that modify the structure, but thread-safe for read-only use. If one *knows* that the collection will never be modified during its lifetime, then one can also know that no locks are needed at read time -- and that happens a *lot* during the lifetime of a Struts-based application.
On the other hand, if the configuration data structures were allowed to change dynamically during the lifetime of the application, we'd have to lock on read accesses as well. That doesn't matter in an app with, say, 10-20 users who play with it occasionally -- it is critically important in apps that are supposed to be Internet scale.
A completely separate discussion could be had about the maintainability and testability of an application that allows dynamic updates to its configuration. I'm very much in the conservative camp on this issue -- if you haven't been able to thoroughly test the exact application environment of your updated code (and this is basically impossible when you allow dynamic updates to the runtime configuration), then you have *zero* guarantees about the quality of the implementation of your app at any given time.
Craig
--------------------------------------------------------------------- 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]
