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

Thank you Craig Ringer for the detailed list of post (I found some by
myself).
Specially, I'm glad to see it is #1 "TODO" on the compliance matters.
http://jdbc.postgresql.org/todo.html#Compliance

As a reminder, I found post (on the net, not only on this forum) about this
issue more than 3 years old!
And still : The driver doesn't implement it.

So,
Does anyone know if there is a plan to implement this feature?

On Wed, Dec 14, 2011 at 3:01 PM, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> 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<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/msg00131.php>
> http://archives.postgresql.**org/pgsql-jdbc/2010-10/**msg00077.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<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
>

--
Sylvain Mougenot