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. > 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. Any alternate solutions are welcome! Dan.
pgpoodqr7zYw4.pgp
Description: PGP signature
