On 4/10/13 9:32 AM, Mike Matrigali wrote:
On 4/10/2013 6:11 AM, Rick Hillegas wrote:
On 4/9/13 1:46 PM, Mike Matrigali wrote:
Derby uses making a connection to shutdown the database, and in
DERBY-6122 it looks like that attempt to shutdown the database
can timeout.
Thanks for raising this issue, Mike. Login timeouts could interfere with
orderly shutdown for several reasons, including:
A) Network problems which slow down LDAP authentication.
B) Heavily loaded databases which need a lot of time to quiesce.
If login timeouts turn out to be a problem for orderly shutdown, one
solution might be to implement an alternative api for bringing down a
database and/or engine. See this very old enhancement request:
DERBY-586. From time to time we get static about these two features of
the Derby shutdown api:
1) It's quirky to shutdown via a startup api.
2) It's annoying that a successful shutdown results in an exception
which the application has to catch.
I agree with 1+2 here.
I do wonder if this is what a user would expect?
Probably not. But with or without timeouts, the Derby shutdown api isn't
what people coming from other databases expect. I think we have to live
with this additional kink as long as we overload the JDBC connection api
this way.
That is sort of what I thought, just wanted to make sure it was current
expected behavior. Is it worth calling this behavior out in 10.10
documentation, I know I was surprised when I first saw it
I think this is a good idea. We document other hurdles which shutdown
must pass, e.g., authentication and database ownership problems. The
fact that you were surprised by this behavior suggests that it will
surprise people who are less familiar with Derby. I have logged
https://issues.apache.org/jira/browse/DERBY-6165 to track this issue.
I do think that we should address DERBY-586 in 10.10.2. I plan to
propose a new shutdown api soon, which we can discuss on that issue.
- then thinking about implementation of shutdown through login
understood from
a code level.
Worst case now a search on this forum will explain.
I'm comfortable with that. I don't think this problem merits re-spinning
10.10.1.
Thanks,
-Rick
Thanks,
-Rick
/mikem
