So, you are sudgesting interface #1 to config? i.e. 100% generic config functions? What kind of enforcement mechanism on presense of config options shall we have then? Alexey Parshin wrote:
In this case, we only have one copy of the config in memory, and the solution is simple - it should be hash-tree in memory, stored as XML when updated. We don't even need to store it on every update, only after some period of time, to ease the disk load. And access to such thing could be something like: CConfig& servletConfig = configuration["servletClass"]; CParam& param = servletConfig["my_param"]; param = 12345.67; /// ... CString strParam = param; int intParam = param;double doubleParam = param; /// ...On 4/26/05, Ilya A. Volynets-Evenbakh <email@example.com> wrote:Alexey Parshin wrote:The difference between SQL approach and config server approach - config server should be faster, have less footprint on the app,Neither is nessesarily true.AND may have XML underneath.And this way - we can just fold it back into app server itself ;-)On 4/26/05, Ilya A. Volynets-Evenbakh <firstname.lastname@example.org> wrote:Well, they will be shared between threads, if that's what you mean, but sharing them between processes? We only have one process per server anyways.What about servlets - they aint going to be a process each?Of course not. That's the whole point of application server - multiple different pages are served by programs in single memory space, so they can share live objects. i.e. session in application server is an object in memory, that is never copied - instead its pointer just passed around. All we have is pool of threads, each serving *connections* (not even thread per servlet).
Authoright © Total Knowledge: 2001-2008