Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E04D4D3EA for ; Fri, 16 Nov 2012 23:35:12 +0000 (UTC) Received: (qmail 88422 invoked by uid 500); 16 Nov 2012 23:35:12 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 88391 invoked by uid 500); 16 Nov 2012 23:35:12 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 88383 invoked by uid 99); 16 Nov 2012 23:35:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Nov 2012 23:35:12 +0000 Date: Fri, 16 Nov 2012 23:35:12 +0000 (UTC) From: "Kathey Marsden (JIRA)" To: derby-dev@db.apache.org Message-ID: <1921050759.126333.1353108912542.JavaMail.jiratomcat@arcas> In-Reply-To: <1600444145.111493.1352856972948.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (DERBY-5994) Different SQL State is returned when executing "shutdown=true" - locally or remotely using ClientDriver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499242#comment-13499242 ] Kathey Marsden commented on DERBY-5994: --------------------------------------- If you agree that this is an embedded/client difference then it would be good to adjust the title accordingly and then address in conjunction with DERBY-2068 in a feature release if deemed worth the risk of changing SQLStates. Perhaps it would be good to send a separate email to the user list about your general replication best practices question: "The reason why this is important is because when using Derby Replication, when replication is started - the databases must be identical and in sync, so the database must be shutdown cleanly, copied over, and replication will be started. Since the Salve Derby must start before Master Derby, it is required to be able to remotely shutdown the Master Derby database from the Slave Derby instance (host). " I am not familiar with replication really at all but this seems a valid best practices question and I wonder if shutdown of the database from the client is the recommended way. As discussed in this thread http://old.nabble.com/How-to-reset-Derby-Database-in-JVM-td34541038.html, client shutdown of the database is not something that is documented or necessarily a good idea. > Different SQL State is returned when executing "shutdown=true" - locally or remotely using ClientDriver > ------------------------------------------------------------------------------------------------------- > > Key: DERBY-5994 > URL: https://issues.apache.org/jira/browse/DERBY-5994 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client, Network Server, Replication > Affects Versions: 10.8.2.2 > Environment: Derby Embedded Network Server - Not specific to operating systems, software platforms or hardware specifications. > Reporter: Oskar Zinger > Attachments: Derby5994Repro.java > > > Different SQL State is returned when executing "shutdown=true" Derby URL attribute while executing the shutdown Database connection locally or remotely. Note: in both cases the client driver is used: "org.apache.derby.jdbc.ClientDriver" > Here is some background information: > - Using the embedded Derby Network Server deployment (derbynet.jar) > - Using the JDBC Derby Client (derbyclient.jar) > - Using the Derby Engine (derby.jar) > Note: in both cases the client driver is used: "org.apache.derby.jdbc.ClientDriver". The only difference is the URL, when host and port is not specified execution happens in the same JVM (local), when host and port is specified execution happens into another JVM (remote). > When executing the following - if database has not been booted yet (or already shutdown) - the SQL State Code is "XJ004": > DriverManager.getConnection("jdbc:derby:MyDatabase;shutdown=true;deregister=false", user, pass); > When executing the following - if database has not been booted yet (or already shutdown) - the SQL State Code is "08004": > DriverManager.getConnection("jdbc:derby://myhost.mycompany.net:1527/MyDatabase;shutdown=true;deregister=false", user, pass); > The SQL State Code of "08004" usually is returned with an SQL Exception if "User Authentication is Invalid" for example username and / or password is incorrect. > Here is the error message: > Error Code: '40000', SQL State Code: '08004' and Exception: 'java.sql.SQLNonTransientConnectionException: The connection was refused because the database ;shutdown=true;deregister=false was not found.' > Separately, the error message "database was not found" is actually misleading because the database actually does exist and it just has not been been booted yet, or it has already been shutdown. The Derby Network Server has not been shutdown, only the database and it is possible to check if the database exists on the file system. > The reason why this is important is because when using Derby Replication, when replication is started - the databases must be identical and in sync, so the database must be shutdown cleanly, copied over, and replication will be started. Since the Salve Derby must start before Master Derby, it is required to be able to remotely shutdown the Master Derby database from the Slave Derby instance (host). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira