From derby-user-return-13177-apmail-db-derby-user-archive=db.apache.org@db.apache.org Thu Oct 21 10:35:32 2010 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 17962 invoked from network); 21 Oct 2010 10:35:32 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Oct 2010 10:35:32 -0000 Received: (qmail 95380 invoked by uid 500); 21 Oct 2010 10:35:31 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 95269 invoked by uid 500); 21 Oct 2010 10:35:29 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 95262 invoked by uid 99); 21 Oct 2010 10:35:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Oct 2010 10:35:29 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [213.199.154.208] (HELO AM1EHSOBE005.bigfish.com) (213.199.154.208) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Oct 2010 10:35:23 +0000 Received: from mail27-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.8; Thu, 21 Oct 2010 10:35:00 +0000 Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1-R.bigfish.com (Postfix) with ESMTP id B78C819904C6 for ; Thu, 21 Oct 2010 10:35:00 +0000 (UTC) X-SpamScore: -24 X-BigFish: VPS-24(zzbb2cK1432N98dN4015L15bfMzz1202hzz8275bh8275dhz2dh2a8h43h61h) X-Spam-TCS-SCL: 0:0 Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1 (MessageSwitch) id 1287657300422528_24026; Thu, 21 Oct 2010 10:35:00 +0000 (UTC) Received: from am1ehsmhs011.bigfish.com (unknown [10.3.201.250]) by mail27-am1.bigfish.com (Postfix) with ESMTP id 429ABA40050 for ; Thu, 21 Oct 2010 10:35:00 +0000 (UTC) Received: from us-voo-smtp05.internal.sungard.corp (216.83.166.46) by am1ehsmhs011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.0.482.44; Thu, 21 Oct 2010 10:34:59 +0000 Received: from us-voo-smtp12.internal.sungard.corp ([168.162.128.54]) by us-voo-smtp05.internal.sungard.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 06:34:58 -0400 Received: from emea-tc2-smtp11.internal.sungard.corp ([10.254.228.141]) by us-voo-smtp12.internal.sungard.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 06:34:58 -0400 Received: from EMEA-EXCHANGE04.internal.sungard.corp ([10.254.226.56]) by emea-tc2-smtp11.internal.sungard.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 11:34:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: does Derby honor the statement.setQueryTimeout(int) ? Date: Thu, 21 Oct 2010 11:34:49 +0100 Message-ID: <1EABF5CBF28C1B498E700756FE70D46C01FFC73E@EMEA-EXCHANGE04.internal.sungard.corp> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: does Derby honor the statement.setQueryTimeout(int) ? Thread-Index: ActwgVKEHvRyjIvAQom6cCTj54PonwAiXOmw References: <1EABF5CBF28C1B498E700756FE70D46C026C7D8D@EMEA-EXCHANGE04.internal.sungard.corp><4CBF099D.4020000@oracle.com><1EABF5CBF28C1B498E700756FE70D46C01FFC73D@EMEA-EXCHANGE04.internal.sungard.corp><4CBF16A8.1040800@oracle.com> From: To: X-OriginalArrivalTime: 21 Oct 2010 10:34:49.0654 (UTC) FILETIME=[96AAB560:01CB710B] X-Reverse-DNS: unknown Hi Knut, Lily, I have created ticket https://issues.apache.org/jira/browse/DERBY-4863 = and attached a sample program to reproduce it. Since in the meantime I was able to circumvent the concrete problem by = adding a dedicated locking mechanism in *our* code, the priority for the = ticket is "none" from my point of view. However, since the problem = exists I've created the ticket as you suggested and also attached code = to reproduce. Best Regards, Florin -----Urspr=FCngliche Nachricht----- Von: Knut Anders Hatlen [mailto:knut.hatlen@oracle.com]=20 Gesendet: Mittwoch, 20. Oktober 2010 20:04 An: derby-user@db.apache.org Betreff: Re: AW: does Derby honor the statement.setQueryTimeout(int) ? Kristian Waagan writes: > On 20.10.10 17:38, Florin.Herinean@sungard.com wrote: >> Hi Kristian, >> >> Changing of the global timeout is not an option, since I need to have = most of the statements behave normally (to wait as long as neccessary to = succeed) and just a few statements with a "fail fast" behavior. > > I don't know if it is an option, but maybe it is possible to change=20 > the lock timeout value (and possibly the deadlock timeout) if the=20 > query timeout is smaller than the lock timeout value. > Is doing this acceptable in principle? > Does anyone know that piece of the code well enough to say if that's a = > viable improvement? Hi Kristian, I think this is possible. The lock manager could retrieve information = about the query timeout from the statement context, and then if = necessary use that to shorten the lock timeout. It sounds like a bug = that we don't already do that. Florin, please file a bug report in JIRA so that we can keep track of = this problem. Thanks, -- Knut Anders