Thread: JDBC Statement.setQueryTimeout : is there plan to implement this?
Query timeout is not supported in JDBC (driver version 9.1-901.jdbc4)
Statement.setQueryTimeout(int seconds) throws an exception when seconds > 0.
(in drivers prior to 8.3 there was no error but it was ignored)
Using Java + transaction management, we are missing this feature badly.
I found people trying to fallback using "SELECT statement_timeout(SEC)".
But this is useless in many cases (I mean transaction manager does it's work independently) :
- my code do not directly decides to start a transaction
- some code may have different transaction settings
So I couldn't easily introduce the good select statement at the right moment.
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.
Sylvain Mougenot
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. Please search the mailing list archives for discussion on this topic: http://www.postgresql.org/search/?m=1&q=setQueryTimeout+&l=&d=-1&s=d <http://www.postgresql.org/search/?m=1&q=setQueryTimeout+&l=&d=-1&s=d> IIRC there are server backend changes required to make it possible to implement setQueryTimeout, and nobody's come up with an acceptable patch. I haven't followed the issue so I could easily be mistaken, though. -- Craig Ringer
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
Thank you Craig Ringer for the detailed list of post (I found some by myself).
--
Sylvain Mougenot
Specially, I'm glad to see it is #1 "TODO" on the compliance matters.
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@ringerc.id.au> wrote:
On 14/12/2011 9:29 PM, Sylvain Mougenot wrote:(following up on last post): See in particular this thread: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.
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
Sylvain Mougenot
On 12/14/2011 11:30 PM, Sylvain Mougenot wrote:
Are you volunteering? Almost all the PgJDBC work is done on a volunteer basis, and the best way to make improvements happen is to do them yourself or contract someone who knows PgJDBC to do the work.
--
Craig Ringer
Thank you Craig Ringer for the detailed list of post (I found some by myself).I haven't heard of any active work on it recently.Specially, I'm glad to see it is #1 "TODO" on the compliance matters.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?
Are you volunteering? Almost all the PgJDBC work is done on a volunteer basis, and the best way to make improvements happen is to do them yourself or contract someone who knows PgJDBC to do the work.
--
Craig Ringer
Replied on pgsql-jdbc; please follow the discussion there. -- Craig Ringer
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