db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein Grovlen - Sun Norway <Oystein.Grov...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-51) Need NetworkServerControl shutdown API method that does not shutdown derby embedded
Date Mon, 24 Apr 2006 10:32:36 GMT
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 


View raw message