geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert \"kebernet\" Cooper" <>
Subject Re: One True Way (TM) of handling configuration files
Date Fri, 08 Aug 2003 18:53:28 GMT
Alex Blewitt wrote:

> Yes, but what about simple changes? Would you have to bounce an app to 
> update it to use a new DB/PW, for example? What would happen to users 
> that were logged into that app (i.e. had HttpSession state) whilst you 
> bounced it? I've had conversations with administrators who complained 
> with some early J2EE servers that the only way of picking up some 
> changes was to bounce the app, which logged all the users off. Not great 
> for trivial changes.
> These are the sort of things I hope we can avoid, regardless of what 
> kind of back-end-configuration-repository is used.
> Alex.

I guess the line there goes to what you consider to be the app. We did 
have a breakpoint on some items that meant restarting the app, but most 
things we just looked at changes between the current running config and 
the new config submission and restarted those services (the DB 
Connection Pools, in your example).  However, all of those issues are 
not really confined to an aguement about file-based config so much as 
how you implement the ability to make changes to running services in the 
code. Gracefully reconfiguring RDBMS pools within our configuration 
service, for example, wasn't a trivial thing to implement.

I'm not sure I see the multiple administrators working on the same app 
as being a huge issue, though. I can't say as I have ever encountered a 
situation where that was a problem. I would be curious, though, what you 
are calling trivial changes. In most environments I have been in, 
anything that wasn't something like changing pool and cache sizes on a 
live server would be something attached to a new build/deploy cycle 
anyway, which would require at least application downtime or dropped 
user sessions.

View raw message