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

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.

--
Craig Ringer