Re: JDBC Statement.setQueryTimeout : is there plan to implement this?

From: David Fetter <david(at)fetter(dot)org>
To: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
Cc: Sylvain Mougenot <smougenot(at)sqli(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
Date: 2011-12-14 16:13:49
Message-ID: 20111214161349.GA31176@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc pgsql-sql

On Wed, Dec 14, 2011 at 10:01:37PM +0800, Craig Ringer wrote:
> On 14/12/2011 9:29 PM, Sylvain Mougenot wrote:
> >Even if the behaviour is not implemented, I guess it could be
> >"mocked" if the call to Statement.setQueryTimeout(int seconds)
> >generated the select statement "SELECT statement_timeout(SEC)". I
> >know this is not ideal but could solve the problem temporarily. I
> >could even be turned on by some driver settings.
> >
>
> (following up on last post): See in particular this thread:
>
> http://archives.postgresql.org/pgsql-jdbc/2010-10/msg00071.php
>
> with posts like:
>
> http://archives.postgresql.org/pgsql-jdbc/2010-10/msg00131.php
> http://archives.postgresql.org/pgsql-jdbc/2010-10/msg00077.php
>
>
> I'm a little concerned about the proposal to use a java.util.Timer,
> as IIRC there are issues with using a Timer in a JavaEE environment.
> I'm struggling to find more than vague references like it being
> "inappropriate for a managed environment" though.
>
> Ah, here:
>
> http://jcp.org/en/jsr/detail?id=236
>
> "JavaTM Platform, Enterprise Edition (Java EE and formally known as
> J2EETM) server containers such as the enterprise bean or web
> component container do not allow using common Java SE concurrency
> APIs such as java.util.concurrent.ThreadPoolExecutor,
> java.lang.Thread, java.util.concurrent.ScheduledThreadPoolExecutor
> or java.util.Timer directly."
>
> and
>
> "java.util.Timer, java.lang.Thread and the Java SE concurrency
> utilities (JSR-166) in the java.util.concurrency package should
> never be used within managed environments, as it creates threads
> outside the purview of the container."
>
> I suspect that PgJDBC will have to get a timer from the container
> via JNDI and fall back to direct instantiation if it is in a Java SE
> environment. I'm not sure how to do that right now or whether it can
> be done in a container-independent way (*shudder*). I'm quite sure
> that using EJB timers is NOT the right way to do it - they're not
> supported by web profile containers and are really intended for
> "business level" timers that should be persistent across
> redeploy/relaunch of appserver/reboot.
>
> I've CC'd David Fetter, the author of the JDBC patch.

Do we have some ideas as to what strategies the Oracle and Microsoft
SQL Server drivers do? As I recall, the MS-SQL Server ones used to
use a Timer thread, although that may have changed. Are there other
relevant drivers whose behavior we should look to?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Craig Ringer 2011-12-15 00:50:11 Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
Previous Message Sylvain Mougenot 2011-12-14 15:30:51 Re: JDBC Statement.setQueryTimeout : is there plan to implement this?

Browse pgsql-sql by date

  From Date Subject
Next Message Craig Ringer 2011-12-15 00:50:11 Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
Previous Message Sylvain Mougenot 2011-12-14 15:30:51 Re: JDBC Statement.setQueryTimeout : is there plan to implement this?