From: David Fetter <david@fetter.org>
To: Craig Ringer <ringerc@ringerc.id.au>
Cc: Sylvain Mougenot <smougenot@sqli.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
Date: Wed, 14 Dec 2011 08:13:49 -0800
Message-ID: <20111214161349.GA31176@fetter.org> (raw)
In-Reply-To: <4EE8AC41.2040505@ringerc.id.au>
References: <CACKdPFjK_UsZ5wExD-RvBbvi6Zo-VYtoxQsCUpWXzTN9kywj7w@mail.gmail.com>
<4EE8AC41.2040505@ringerc.id.au>
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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: david@fetter.org, ringerc@ringerc.id.au, smougenot@sqli.com
Subject: Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
In-Reply-To: <20111214161349.GA31176@fetter.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox