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 <ring...@ringerc.id.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