[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Configuration, take2
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).