Re: setQueryTimeout woes

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: setQueryTimeout woes
Date: 2013-12-05 20:43:07
Message-ID: CADK3HHJnfkTWd3CbqGuZ38ETcQbGkXtrveu2bPDZhG_f5NAMCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Thanks for this, I'll take a look shortly

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Thu, Dec 5, 2013 at 2:22 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com>wrote:

> Our setQueryTimeout() is still a few bricks shy of a load.
>
> The fundamental problem is that the cancel timer is started on the
> setQueryTimeout() call - not when you actually start to execute a query.
> That leads to a couple of bugs:
>
> 1. If you call setQueryTimeout(5), wait 10 seconds, and call execute(),
> the cancel timer has already expired, and the statement will be allowed to
> run forever. Likewise, if you call setQueryTimeout(5), wait 4 seconds, and
> call execute(), the statement will be canceled after only 1 second.
>
> 2. If you call setQueryTimeout on a PreparedStatement, and execute the
> same statement several times, the timeout only takes affect on the first
> statement.
>
> 3. If you call setQueryTimeout on one Statement, but don't execute it, the
> timer will still fire, possible on an unrelated victim Statement.
>
> And one more bug:
>
> The run() method in the timer task contains a finally-block that calls
> killTimer(), but by the time that runs, the PreparedStatement might already
> have started running a new query, with a new timeout. And the finally-block
> erroneously cancels the timeout timer on the next query. I was getting
> spurious failures in the attached testSetQueryTimeoutOnPrepared() test
> case, which mysteriously went away when I added a simple
> System.out.println() call between the queries. That was enough of a delay
> to mask the race condition. The finally-block seems unnecessary to me, the
> timer has already fired so there's no harm in leaving the object in place
> until the finally-block in the execute() method removes it.
>
> I created a pull request on github about this. Patch also attached here.
>
> - Heikki
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Scott Carr 2013-12-06 21:25:58 Re: Timestamp issue from ojdbc5 & ojdbc6
Previous Message Heikki Linnakangas 2013-12-05 19:22:50 setQueryTimeout woes