Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 20 Apr 2006 16:38:57 +0200
From: John Embretsen <John.Embretsen@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-51) Need NetworkServerControl shutdown
 API method that does not shutdown derby embedded
In-reply-to: <44466923.9050603@sbcglobal.net>
To: derby-dev@db.apache.org
Message-id: <44479D01.8000505@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5 (X11/20060113)
References: <583728.1145435658129.JavaMail.jira@brutus>
 <44466923.9050603@sbcglobal.net>

Kathey Marsden wrote:
> John H. Embretsen (JIRA) wrote:
> 
>> Kathey Marsden commented:
>>> I don't think the default behaviour for the API shutdown can be changed at this point.
>>>    
>>>
>> Why is that?
>>
>>  
>>
> My thinking was that users may be dependent on the existing behavour,
> but if it is documented that way ...
> 
>> Specifically, I found the following statement in the admin guide,  http://db.apache.org/derby/docs/dev/adminguide/tadminconfigshuttingdownthenetworkserver.html, for trunk:
>>
>>  
>>
> I am less convinced that it can't be changed.  The alternate approach to
> the one I proposed would be:
> 
> 1)  Leave DERBY-51 open as is.
> 2) Log a bug that network server does not shutdown  databases properly
> when network server is shutdown.
> 3) Determine what the behaviour is/should be when embedded is shutdown
> or network  server is shutdown if  Network Server was started with the
> derby.drda.startNetworkServer property.
> 
> This approach poses some risk to applications that might have been
> relying on the bug (2) but  it could be mitigated since we document it
> this way and doing this way makes sense. Proper notification in the
> Release Notes would be required and we probably should give early
> notification to the user base.
> 
>  How should we proceed?

Well, I think your alternate approach makes more sense, but I don't have very 
strong feelings about it.

Either way, I believe having the same default behavior for the CLI (command 
line interface) and the API is a positive thing. Not having the CLI shut down 
Derby when the network server is shut down (via the CLI) does not make much 
sense to me...

However, other people on the list seem to like your first suggestion, so I 
understand if that is what we end up with.


-- 
John