db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joel Rosi-Schwartz <Joel.Rosi-Schwa...@Etish.org>
Subject Re: SQL exception on shutdown
Date Mon, 20 Sep 2004 19:45:21 GMT
On Monday 20 September 2004 17:05, Daniel John Debrunner wrote:
> Joel Rosi-Schwartz wrote:
> > It seems that shutting down a database always throws an exception,
> > whether or not the shutdown was successful. On success the ERROR code
> > embedded in the exception message is "ERROR 08006: Database 'DBNAME'
> > shutdown." This makes it difficult, if not impossible, to robustly check
> > if the shutdown was successful or not. Yes, a string compare could be
> > done to the beginning of the message, but this is fragile if the error
> > message changes.
> A string compare should be made on the SQL state
> (SQLException.getSQLState()), not the text of the message, as the
> message changes with locale. A change in the SQL state would be a change
> of API and therefore should not occur without thought.
Thanks for pointing that out, I discovered this belatedly after posting the 

> > What is the
> > value of the exception on success? I think this should changed, if for no
> > other reason then throwing an exception on success is really against best
> > practises and an anti-pattern to be avoided.
> The issue is that standard JDBC getConnection() method calls (either
> DriverManager or DataSource) are used to push the shutdown request to
> Derby. A successful return from these methods would require a Connection
> object to be returned. It seemed strange to return a connection object
> to a database or system that was no longer active, what state would the
> Connection be in, closed? So the decision was made to throw an
> exception, which I think matches spirit of the JDBC spec. (Null as a
> return is not supported by the spec).
> The use of the standard JDBC mechanisms to push the shutdown request
> means that the request can be passed to Derby by any networked JDBC
> driver (e.g. DB2 universal driver, RmiJDBC, Weblogic's old Tengah
> driver) as well as embedded.

That was a really pertinent expanation, thanks. I really helps to understand 
the whys of these things and it would really be nice if the documentation for 
Derby discussed such issuse. Thank you very much for taking the time to 
explain it so clearly.

- joel

> Any alternate solutions are welcome!
I'll give it some thought ;-)
> Dan.

View raw message