Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 61498 invoked from network); 21 Mar 2006 15:14:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Mar 2006 15:14:57 -0000 Received: (qmail 70705 invoked by uid 500); 21 Mar 2006 15:14:53 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 70659 invoked by uid 500); 21 Mar 2006 15:14:53 -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 70650 invoked by uid 99); 21 Mar 2006 15:14:53 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Mar 2006 07:14:53 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Mar 2006 07:14:52 -0800 Received: from ajax (localhost.localdomain [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id 657A86ACA9 for ; Tue, 21 Mar 2006 15:14:31 +0000 (GMT) Message-ID: <103391414.1142954071410.JavaMail.jira@ajax> Date: Tue, 21 Mar 2006 15:14:31 +0000 (GMT) From: "Daniel John Debrunner (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-1090) Implement Connection.isValid as defined by JDBC4 In-Reply-To: <1632067244.1141853139141.JavaMail.jira@ajax> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1090?page=comments#action_12371245 ] Daniel John Debrunner commented on DERBY-1090: ---------------------------------------------- The query case actually seems somewhat harder to me, and one needs to understand the code far more, than the isClosed approach. Maybe this knowledge needs to exist for the client implementation anyway. I think one has to see how many ways the query can fail and then see how many map to the connection being not valid. I don't believe the query failing, always means the connection is not valid. If the query failed due to out of memory error, then the connection is still valid. There's no requirement for the embedded and client dirver to have identical implementations, the embedded gains performance by having direct access to the engine, something that is clearly not possible with the client. This naturally leads to different implementations for various methods. > Implement Connection.isValid as defined by JDBC4 > ------------------------------------------------ > > Key: DERBY-1090 > URL: http://issues.apache.org/jira/browse/DERBY-1090 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Fix For: 10.2.0.0 > > The Javadoc for JDBC4 says this about Connection.isValid: > boolean isValid(int timeout) throws SQLException > Returns true if the connection has not been closed and is still valid. The driver shall submit a query on the connection or use some other mechanism that positively verifies the connection is still valid when this method is called. > The query submitted by the driver to validate the connection shall be executed in the context of the current transaction. > Parameters: timeout - - The time in seconds to wait for the database operation used to validate the connection to complete. If the timeout period expires before the operation completes, this method returns false. A value of 0 indicates a timeout is not applied to the database operation. > Returns: true if the connection is valid, false otherwise -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira