db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: [jira] Commented: (DERBY-51) Need NetworkServerControl shutdown API method that does not shutdown derby embedded
Date Mon, 24 Apr 2006 14:37:08 GMT
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.

View raw message