db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Re: [jira] Commented: (DERBY-51) Need NetworkServerControl shutdown API method that does not shutdown derby embedded
Date Fri, 21 Apr 2006 19:14:38 GMT
>> I am less convinced that it can't be changed.  The alternate approach to
>> the one I proposed would be:

I feel like there is general consensus about this topic, although that
might be surprising because several opinions and proposals have been
stated so far. Let me state what I think the general consensus is, so
that we can see how best to move forward.

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.

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.

This does change the behavior in the simple Network Server case, but I
think it changes it to the behavior that is what most users expect.

An interesting question is whether shutting down the database(s) could
fail, and, if so, what the Network Server shutdown code should do if it
encounters such a failure: does it shutdown anyway? Does it abort the
shutdown and stay up and try to tell the user about the problem?

I'd like to stop here, to see whether people feel I've captured the
discussion correctly up to this point.

thanks,

bryan




Mime
View raw message