From derby-user-return-13173-apmail-db-derby-user-archive=db.apache.org@db.apache.org Wed Oct 20 16:07:08 2010 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 37958 invoked from network); 20 Oct 2010 16:07:08 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Oct 2010 16:07:08 -0000 Received: (qmail 82517 invoked by uid 500); 20 Oct 2010 16:07:08 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 82494 invoked by uid 500); 20 Oct 2010 16:07:08 -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 82487 invoked by uid 99); 20 Oct 2010 16:07:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Oct 2010 16:07:08 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [98.139.53.220] (HELO nm23-vm0.bullet.mail.ac4.yahoo.com) (98.139.53.220) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 20 Oct 2010 16:07:00 +0000 Received: from [98.139.52.194] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 20 Oct 2010 16:06:38 -0000 Received: from [98.139.52.157] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 20 Oct 2010 16:06:38 -0000 Received: from [127.0.0.1] by omp1040.mail.ac4.yahoo.com with NNFMP; 20 Oct 2010 16:06:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 911706.33956.bm@omp1040.mail.ac4.yahoo.com Received: (qmail 31006 invoked by uid 60001); 20 Oct 2010 16:06:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1287590791; bh=MxKADf/w9rYcqrjEKTThQQND0LsrrSN2T2GE1HrOJ/Y=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DYMRXcJ62lWqsuK3QBlmMOW2Wwe+nCsROIkHhtBdT8vVNNrSNkUG4iihOgxx/SZFY3bdGUGsiUg/pl2A4NHnyF0ubD9Jy8ymSF6I5QaS5Haz/ke8+yzM/FwXqMTvuRBhAn5ECHobNWlOCdVnpwz0LPH9ptDtlSDURh9ALLPNQYg= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=0K5up2EV243cK0BDwVAPdXrQskZMId01VV87WkdvcXVRWx9gKw9nkhK8nlcUcblzR+pgo2TXuSZNcI2fYjau5ERoMubiGEruShDojBGvW1qdBWyIUzF1umEUpe8Eu5EQDrY35P10RYrDNLiCYyxtnvmZ05OkyFB3wDa1Ir/Sgys=; Message-ID: <786536.30985.qm@web65715.mail.ac4.yahoo.com> X-YMail-OSG: kybpEMcVM1mGVfdNSQ9NOdHs3dLBrg8cAbCOw4b26.xhfte K.6M- Received: from [76.126.97.152] by web65715.mail.ac4.yahoo.com via HTTP; Wed, 20 Oct 2010 09:06:30 PDT X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.106.282862 References: <1EABF5CBF28C1B498E700756FE70D46C026C7D8D@EMEA-EXCHANGE04.internal.sungard.corp> <4CBF099D.4020000@oracle.com> <1EABF5CBF28C1B498E700756FE70D46C01FFC73D@EMEA-EXCHANGE04.internal.sungard.corp> Date: Wed, 20 Oct 2010 09:06:30 -0700 (PDT) From: Lily Wei Subject: Re: AW: does Derby honor the statement.setQueryTimeout(int) ? To: Derby Discussion In-Reply-To: <1EABF5CBF28C1B498E700756FE70D46C01FFC73D@EMEA-EXCHANGE04.internal.sungard.corp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-62001655-1287590790=:30985" --0-62001655-1287590790=:30985 Content-Type: multipart/alternative; boundary="0-32947391-1287590790=:30985" --0-32947391-1287590790=:30985 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Florin:=0A So glad to hear derby user is using 10.6.2.1. I suspect t= here might be =0Asomething more complicated than Statement.QueryTimeout was= not working. Is it =0Apossible for you to reproduce a smaller test case to= allow people to further =0Ainvestigate the case?=0A =0A Like Kristian = pointed out, Statement.QueryTimeout should take effect. I =0Aattach a repro= that is using Statement.QueryTimeout. I tested against 10.6.2.1 =0Arelease= and it is working for me.=0A =0A =0ABest Regards,=0ALily=0A=0A=0A=0A______= __________________________=0AFrom: "Florin.Herinean@sungard.com" =0ATo: derby-user@db.apache.org=0ASent: Wed, October 20,= 2010 8:38:11 AM=0ASubject: AW: does Derby honor the statement.setQueryTime= out(int) ?=0A=0AHi Kristian,=0A=0AChanging of the global timeout is not an = option, since I need to have most of =0Athe statements behave normally (to = wait as long as neccessary to succeed) and =0Ajust a few statements with a = "fail fast" behavior.=0A=0AThe concrete problem: I have a kind of a timer t= hat fires events at regular =0Aintervals (5 sec) and I have to perform some= actions. It might be possible under =0Acertain circumstances that the perf= orming of the actions take (much) longer than =0Athe fixed rate of the time= r, so that the next events are fired before the long =0Arunning one is fini= shed. However, if the actions are involving the same sets of =0Arows, I wan= t that the overlapping ones to fail fast and roll back the =0Atransaction.= =0A=0ANow because Derby is waiting indefinitely, this scenario (events are = comming via =0Ajms messages) will lead to the consumming of all available d= atabase connections, =0Asince for each jms message a new thread/transaction= is created and implicitely a =0Anew connection.=0A=0ARegards,=0A=0AFlorin= =0A=0A-----Urspr=FCngliche Nachricht-----=0AVon: Kristian Waagan [mailto:kr= istian.waagan@oracle.com] =0AGesendet: Mittwoch, 20. Oktober 2010 17:24=0AA= n: derby-user@db.apache.org=0ABetreff: Re: does Derby honor the statement.s= etQueryTimeout(int) ?=0A=0A=0A On 20.10.10 17:16, Florin.Herinean@sungard.= com wrote:=0A>=0A> Hi everybody,=0A>=0A> I'm using Derby latest 10.6.2.1 an= d I'm having a problem with =0A> statement.setQueryTimeout(int).=0A>=0A> Na= mely I want to set a small value for the timeout (5 seconds) so that =0A> t= he statement (an update statement) will fail (relatively) fast if =0A> some= other transaction is holding a write lock on the same row.=0A>=0A> The pro= blem is that setQueryTimeout seems to be ignored, and the =0A> update is wa= iting until the global timeout - 60+ seconds.=0A>=0A> Is that a known probl= em with Derby ? Or am I doing something wrong ?=0A>=0A=0AHi Florian,=0A=0AI= 'm not sure, but if Derby is waiting for a lock, it may not honor the query= =0Atimeout.=0AIf the statement is doing "normal processing", the query tim= eout should take =0Aeffect. If your application code is set up correctly fo= r retrying, is it an =0Aoption to lower the lock timeout as well?=0A=0A=0AR= egards,=0A--=0AKristian=0A=0A> Best Regards,=0A>=0A> Florin Herinean=0A>=0A= =0A=0A --0-32947391-1287590790=:30985 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A=0A

Hi Florin:

=0A= =0A

     So glad to hear=0Aderby user is using 10.6.2.1. I suspect there might be= something more=0Acomplicated than Statement.QueryTimeout was not working. = Is it possible for you=0Ato reproduce a smaller test case to allow people t= o further investigate the=0Acase?

=0A=0A

 =

=0A=0A

     Like Kristian pointed out,=0AStatement.Qu= eryTimeout should take effect. I attach a repro that is using=0AStatement.Q= ueryTimeout. I tested against 10.6.2.1 release and it is working for=0Ame.<= /p>=0A=0A

 

=0A=0A

 

=0A=0A

Best Regards,

=0A=0A

Lily

=0A=0A

From:= "Florin.Herinean@sungard.com" <Florin.Herinean@sungard.com>
To: derby-user@db.apache.orgSent: Wed, October 20, 20= 10 8:38:11 AM
Subject: = AW: does Derby honor the statement.setQueryTimeout(int) ?

=0A= 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 n= eccessary to succeed) and just a few statements with a "fail fast" behavior= .

The concrete problem: I have a kind of a timer that fires events a= t regular intervals (5 sec) and I have to perform some actions. It might be= possible under certain circumstances that the performing of the actions ta= ke (much) longer than the fixed rate of the timer, so that the next events = are fired before the long running one is finished. However, if the actions = are involving the same sets of rows, I want that the overlapping ones to fa= il fast and roll back the transaction.

Now because Derby is waiting = indefinitely, this scenario (events are comming via jms messages) will lead= to the consumming of all available database connections, since for each jm= s message a new thread/transaction is created and implicitely a new connection.

Regards,

Florin

-----Urspr=FCngliche Nach= richt-----
Von: Kristian Waagan [mailto:kristian.waagan= @oracle.com]
Gesendet: Mittwoch, 20. Oktober 2010 17:24
An: derby-user@db.apache.org
Betreff: Re: does Derby honor the = statement.setQueryTimeout(int) ?


  On 20.10.10 17:16, Florin.Herinean@sungard.com wrote:
>
> Hi eve= rybody,
>
> I'm using Derby latest 10.6.2.1 and I'm having a pr= oblem with
> statement.setQueryTimeout(int).
>
> Namely = I want to set a small value for the timeout (5 seconds) so that
> th= e statement (an update statement) will fail (relatively) fast if
> s= ome other transaction is holding a write lock on the same row.
>
>= The problem is that setQueryTimeout seems to be ignored, and the
> = update is waiting until the global timeout - 60+ seconds.
>
> I= s that a known problem with Derby ? Or am I doing something wrong ?
>=

Hi Florian,

I'm not sure, but if Derby is waiting for a lock= , it may not honor the query timeout.
If the statement is doing "normal = processing", the query timeout should take effect. If your application code= is set up correctly for retrying, is it an option to lower the lock timeou= t as well?


Regards,
--
Kristian

> Best Regards,<= br>>
> Florin Herinean
>



=0A
=0A=0A --0-32947391-1287590790=:30985-- --0-62001655-1287590790=:30985 Content-Type: text/plain; name="StatementTimeout.java" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="StatementTimeout.java" CmltcG9ydCBqYXZhLnNxbC5Db25uZWN0aW9uOwppbXBvcnQgamF2YS5zcWwu RHJpdmVyTWFuYWdlcjsKaW1wb3J0IGphdmEuc3FsLlJlc3VsdFNldDsKaW1w b3J0IGphdmEuc3FsLlN0YXRlbWVudDsKCi8qIAogKiBUaGlzIGlzIGEgcmVw cm8gZm9yIHNob3dpbmcgdGhhdCBzZXR0aW5nIGEgc3RhdGVtZW50IHRpbWVv dXQgZm9yCiAqIHRoZSBjbGllbnQgZHJpdmVyIGFsc28gYWZmZWN0cyB0aGUg bWF4aW11bSB0aW1lIHRoYXQgYSBxdWVyeQogKiBpcyBhbGxvd2VkIHRvIGV4 ZWN1dGUuCiAqIAogKiBUbyBydW4gdGhpcyByZXBybzoKICogCiAqIDEuIFN0 YXJ0IGEgRGVyYnkgc2VydmVyCiAqIDIuIENoYW5nZSB0aGUgamRiYyB1cmwg dG8geW91ciBzZXJ2ZXIgYW5kIHBvcnQgbnVtYmVyCiAqIDMuIFJ1biB0aGUg cHJvZ3JhbS4KICogCiAqIEl0IHNob3VsZCBmYWlsIHdpdGggYW4gZXhjZXB0 aW9uLgogKgogKiBUbyBtYWtlIHRoZSBxdWVyeSBzdWNjZWVkLCByZW1vdmUg dGhlIGZvbGxvd2luZyBjb2RlIGxpbmU6CiAqCiAqIFN0YXRlbWVudC5zZXRR dWVyeVRpbWVvdXQoNSk7CiAqCiAqIE5vdGUgdGhhdCB3aXRob3V0IHRoaXMg dGltZW91dCwgdGhlIHByb2dyYW0gbWlnaHQgdGFrZSAyIHRvIAogKiAxMCBt aW51dHRlcyB0byBjb21wbGV0ZS4KICovCgoKCnB1YmxpYyBjbGFzcyBTdGF0 ZW1lbnRUaW1lb3V0CnsKICAgIC8qIENsaWVudC1TZXJ2ZXIgRGVyYnkgKi8K ICAgIHN0YXRpYyBTdHJpbmcgZHJpdmVyID0gIm9yZy5hcGFjaGUuZGVyYnku amRiYy5DbGllbnREcml2ZXIiOwogICAgc3RhdGljIFN0cmluZyBqZGJjVXJs ID0gImpkYmM6ZGVyYnk6Ly9sb2NhbGhvc3Q6MTUyNy9kZXJieURCO2NyZWF0 ZT10cnVlIjsKCgoKICAgIHB1YmxpYyBzdGF0aWMgdm9pZCBtYWluKFN0cmlu Z1tdIGFyZ3MpCiAgICB7CiAgICAgICAgdHJ5IHsKICAgICAgICAgICAgLy8g TG9hZCB0aGUgZHJpdmVyCiAgICAgICAgICAgIENsYXNzLmZvck5hbWUoZHJp dmVyKS5uZXdJbnN0YW5jZSgpOwoKCiAgICAgICAgICAgIC8vIEdldCBhIGNv bm5lY3Rpb24gYW5kIGEgc3RhdGVtZW50CiAgICAgICAgICAgIENvbm5lY3Rp b24gY29ubiA9IERyaXZlck1hbmFnZXIuZ2V0Q29ubmVjdGlvbihqZGJjVXJs KTsKICAgICAgICAgICAgU3RhdGVtZW50IHMgPSBjb25uLmNyZWF0ZVN0YXRl bWVudCgpOwoKICAgICAgICAgICAgLy8gU2V0IGEgU3RhdGVtZW50IHRpbWVv dXQKCSAgICBzLnNldFF1ZXJ5VGltZW91dCg1KTsKCSAgICBTeXN0ZW0ub3V0 LnByaW50bG4oIlNldCBzdGF0ZW1lbnQgdGltZW91dCB0byA1IHNlY29uZHMi KTsKICAgICAgICAgICAgbG9uZyBiZWZvcmUgPSBTeXN0ZW0uY3VycmVudFRp bWVNaWxsaXMoKTsKCiAgICAgICAgICAgIC8vIEV4ZWN1dGUgYSAibG9uZyIg cXVlcnkgdGhhdCB0YWtlcyBhYm91dCAyLTEwIG1pbnV0ZXMKICAgICAgICAg ICAgUmVzdWx0U2V0IHJzID0gcy5leGVjdXRlUXVlcnkoIlNFTEVDVCBDT1VO VCgqKSBGUk9NIFNZUy5TWVNDT0xVTU5TIHQwLCBTWVMuU1lTQ09MVU1OUyB0 MSwgU1lTLlNZU0NPTFVNTlMgdDIsIFNZUy5TWVNDT0xVTU5TIHQzIik7Cgog ICAgICAgICAgICBsb25nIGFmdGVyID0gU3lzdGVtLmN1cnJlbnRUaW1lTWls bGlzKCk7CgogICAgICAgICAgICB3aGlsZSAocnMubmV4dCgpKSB7CiAgICAg ICAgICAgICAgICBTeXN0ZW0ub3V0LnByaW50bG4oIk51bWJlciBvZiByZWNv cmRzOiAiICsgcnMuZ2V0SW50KDEpKTsKICAgICAgICAgICAgfQoKICAgICAg ICAgICAgU3lzdGVtLm91dC5wcmludGxuKCJRdWVyeSB0aW1lOiAiICsgKGFm dGVyLWJlZm9yZSkgKyAiIG1zIik7CiAgICAgICAgICAgIAogICAgICAgICAg ICBycy5jbG9zZSgpOwogICAgICAgICAgICBjb25uLmNsb3NlKCk7CiAgICAg ICAgfSBjYXRjaCAoRXhjZXB0aW9uIGUpIHsKICAgICAgICAgICAgU3lzdGVt Lm91dC5wcmludGxuKCJFeGNlcHRpb24gdGhyb3duOiAiICsgZSk7CiAgICAg ICAgICAgIGUucHJpbnRTdGFja1RyYWNlKFN5c3RlbS5vdXQpOwogICAgICAg IH0KICAgIH0KfQo= --0-62001655-1287590790=:30985--