Oystein Grovlen - Sun Norway wrote:
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.
At a minimum I think we should implement two shutdown modes (by adding
one new NetworkServerControl flag). The current command does clean up
including shutdown of all the databases (just like the parameter
implies: ..NetworkServerControl -shutdown) the new mode just ends the
Server (like is done now: ..NetworkServerControl -killServer ?). Using
a term like 'kill' for the mode that does *NOT* shutdown down databases
will indicate that is is an more abrupt ending.
Issuing a warning and allowing an abort of the shutdown/kill when there
are existing connections is a nicety but I think less important than
having a clean (from a database standpoint) shutdown. I would argue
that people that knowingly implement an embedded server architecture
(i.e. dual-access configuration in which there is also embedded access
to the database(s) within the same application) are savvy enough to
understand the implications of dual-access and mange it in an
appropriate manner.
