Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 70778 invoked from network); 3 Aug 2009 19:43:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Aug 2009 19:43:34 -0000 Received: (qmail 71378 invoked by uid 500); 3 Aug 2009 19:43:39 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 71301 invoked by uid 500); 3 Aug 2009 19:43:39 -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 71293 invoked by uid 99); 3 Aug 2009 19:43:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Aug 2009 19:43:39 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Aug 2009 19:43:35 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C6910234C045 for ; Mon, 3 Aug 2009 12:43:14 -0700 (PDT) Message-ID: <1019596425.1249328594799.JavaMail.jira@brutus> Date: Mon, 3 Aug 2009 12:43:14 -0700 (PDT) From: "Tiago R. Espinha (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Created: (DERBY-4334) Invoking certain methods on PreparedStatements after the underlying connection changed forces repreparing MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org Invoking certain methods on PreparedStatements after the underlying connection changed forces repreparing --------------------------------------------------------------------------------------------------------- Key: DERBY-4334 URL: https://issues.apache.org/jira/browse/DERBY-4334 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.6.0.0 Reporter: Tiago R. Espinha Whenever we invoke methods like isClosed() or getMetaData() on prepared or callable statements after the underlying connection changed, these methods will try to reprepare the statement. This becomes an issue if in the meanwhile, the query became obsolete (e.g. querying a table that was dropped in the meanwhile). For example, if we start a transaction and prepare a statement with "SELECT * FROM FOO;" then drop FOO with a parallel regular connection and try to invoke the said methods on the statement, a repreparement will be attempted. Since FOO no longer exists, it will throw an exception. I fixed this issue on DERBY-4310 for the .close() calls on Prepared and Callable statements, but this will require more extensive work to convert the remaining methods that try to do a getRealStatement() on the XAStatementControl. I will be attaching a repro that pops this issue with the isClosed() call. The approach I used in DERBY-4310 was to add a couple of methods to XAStatementControl that act directly on the real statement object and close them right away, without attempting to reprepare. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.