Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1509729814.1142976939252.JavaMail.jira@ajax>
Date: Tue, 21 Mar 2006 21:35:39 +0000 (GMT)
From: "Olav Sandstaa (JIRA)" <derby-dev@db.apache.org>
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

    [ http://issues.apache.org/jira/browse/DERBY-1090?page=comments#action_12371306 ] 

Olav Sandstaa commented on DERBY-1090:
--------------------------------------

Thanks for commenting on this, Dan. I agree that using a query is more complicated than just checking for isClosed. So if checking for isClosed is sufficient to verify that the connection is "valid" we should go for that approach in the embedded driver as it is less complex and has better performance. 

Still, I think the purpose of adding the isValid method to the JDBC standard is to positively determine that it is possible to run queries on it. I am not convinced that your example of a simple query on the connection failing due to out of memory should still return that the connection is "valid"? I expect this is a method that will be used together with a connection pool implementation where either the pool or the user will use this for "ensuring" the connection is "valid" before it is used for something. And having a connection that returns out of memory errors on every query is not something that an application would think is a "useful" connection to have around (on the other side, creating a new connection does probably not make the situation any better in this case). The JavaDoc for isValid (see the test in the Jira issue) strongly indicates that we actually should take the cost of running a query against the database.

Anyway, I have no strong opinions on whether to just check isClosed or issue a query against the database. But since I now happen to have a patch that solves this using a query I will upload this patch tonight. Tomorrow moring I will upload a new patch that is only checking for isClosed. I do not expect anyone to do a review or commit any of these, but it might trigger some more comments and opinions from other on the list. 

> 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