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]
