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.
