Bryan Pendleton wrote:
1) There are two basic configurations of interest here: a) In the simple Network Server case, the Network Server process is providing access to the database(s) over DRDA b) In the dual-access configuration, an application which has established embedded access to the database(s) is also providing networked access to those same database(s) by creating a Network Server object in the same application.2) Currently, when the Network Server is shut down, it does NOT shut down the database(s) that it has been providing access to. This is important for users of the dual-access configuration, because they may well be continuing to access the database(s) through the embedded connection.
It is a bit unfortunate that the same term (shutdown) is used in both cases. It would have better if one used start/stop for the network server and reserved shutdown for the database. I guess it is too late to do anything with that.
3) Unfortunately, in the simple Network Server case, this behavior is very non-intuitive, as most users would expect that when they shut down the Network Server in a clean fashion, that this would also shut down the database(s) in a clean fashion. 4) Unconditionally changing behavior (2) is worrisome, because it could affect existing applications (of either configuration). We should not take such a step lightly. I hope that there is general agreement about the above, so please indicate if I've got it wrong. In terms of what changes to make to the behavior of the Network Server, it seems that there are two basic proposals: - Don't add any new flags or arguments or commands; just make the Network Server shutdown do the right thing. Of course, this depends on whether we can agree on what the right thing is in all cases, and on whether the code has enough information to be able to do it. - Allow the end user to choose the shutdown behavior, by indicating whether they just want to shut down the Network Server, or whether they also want to shut down the database(s). My preference would be the former, because I think it would be less complex, easier to use, and simpler to document. I think that when the simple Network Server shuts down, it should shut down the databases it was providing access to, but when the Network Server has been started in a dual-access configuration in which there is also embedded access to the database(s) within the same application, the Network Server should *not* shut down the databases when it is shutting down.
What if the existing method is changed to shut down the database if there is no other open connections to it? We would then probably have to add an option to force a shutdown even when there is open connections. So maybe this is just a variant of the second alternative above.
-- Øystein
