Re: Configuration, take2

[Alexey Parshin <alexeyp@gmail.com>]

Not sure. We may request a list of options that must be defined as a
property of the option group.. I don't really like it, but that would
work


On 4/26/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> 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 <ilya@total-knowledge.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 <ilya@total-knowledge.com> 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).
> >>
> >>
> 
> 


-- 
Alexey Parshin,

Senior DBA,
Tactical Telesolutions,
San Francisco