From derby-dev-return-1421-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Fri Dec 17 21:41:48 2004 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 90899 invoked from network); 17 Dec 2004 21:41:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 17 Dec 2004 21:41:48 -0000 Received: (qmail 42732 invoked by uid 500); 17 Dec 2004 21:41:44 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 42699 invoked by uid 500); 17 Dec 2004 21:41:44 -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: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 42665 invoked by uid 99); 17 Dec 2004 21:41:43 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from exchange.sun.com (HELO exchange.sun.com) (192.18.33.10) by apache.org (qpsmtpd/0.28) with SMTP; Fri, 17 Dec 2004 13:40:38 -0800 Received: (qmail 11820 invoked from network); 17 Dec 2004 17:40:15 -0000 Received: from localhost (HELO nagoya) (127.0.0.1) by nagoya.betaversion.org with SMTP; 17 Dec 2004 17:40:15 -0000 Message-ID: <384523574.1103305215888.JavaMail.apache@nagoya> Date: Fri, 17 Dec 2004 09:40:15 -0800 (PST) From: "Ali Demir (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-31) Statement.setQueryTimeout() support. In-Reply-To: <1366568654.1096916132120.JavaMail.apache@nagoya> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N [ http://nagoya.apache.org/jira/browse/DERBY-31?page=comments#action_56831 ] Ali Demir commented on DERBY-31: -------------------------------- When a time out is set to n millis, and if the query takes n+m millis, then caller would expect that time out occurs around n millis and not wait until n+m. Also, when the timeout occurs, the processing of the query should have been stopped and there should not be any locks held after timeout. Therefore, a simple solution that simply checks how long the query processing is taking is not enough. The internals of the system need to know that it should stop the query and release any locks held by it when the timeout occurs. > Statement.setQueryTimeout() support. > ------------------------------------ > > Key: DERBY-31 > URL: http://nagoya.apache.org/jira/browse/DERBY-31 > Project: Derby > Type: New Feature > Components: JDBC > Environment: ALL > Reporter: Ali Demir > > Calling Statement.setQueryTimeout() throws exception saying that function is not supported. This is an important JDBC feature and is limiting our options to use Derby with our JDBC code. Implementing this JDBC function would make Derby much easier to adopt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira