Re: Configuration, take2

[Alexey Parshin <alexeyp@gmail.com>]

I'm not that concerned about enforcing yet. However the speed and ease
of use for the 1 is the best. We keep everything in memory, we save
changes from time to time. Every changed option group can be
validated, and we can always define the validation routine.

On 4/26/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> Or use interface #2 or #3 from original email,
> which actually force you to have some options present/accessible.
> 
> Alexey Parshin wrote:
> 
> >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).
> >>>>
> >>>>
> 
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
> 
> 


-- 
Alexey Parshin,

Senior DBA,
Tactical Telesolutions,
San Francisco