pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedJDBC Statement.setQueryTimeout : is there plan to implement this?
18+ messages / 7 participants
[nested] [flat]
* JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-14 13:29 Sylvain Mougenot <smougenot@sqli.com>
0 siblings, 2 replies; 18+ messages in thread
From: Sylvain Mougenot @ 2011-12-14 13:29 UTC (permalink / raw)
To: pgsql-sql
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-14 13:42 Craig Ringer <ringerc@ringerc.id.au>
parent: Sylvain Mougenot <smougenot@sqli.com>
1 sibling, 0 replies; 18+ messages in thread
From: Craig Ringer @ 2011-12-14 13:42 UTC (permalink / raw)
To: Sylvain Mougenot <smougenot@sqli.com>; +Cc: pgsql-sql
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-14 14:01 Craig Ringer <ringerc@ringerc.id.au>
parent: Sylvain Mougenot <smougenot@sqli.com>
1 sibling, 2 replies; 18+ messages in thread
From: Craig Ringer @ 2011-12-14 14:01 UTC (permalink / raw)
To: Sylvain Mougenot <smougenot@sqli.com>; +Cc: pgsql-sql@postgresql.org, David Fetter <david@fetter.org>
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-14 15:30 Sylvain Mougenot <smougenot@sqli.com>
parent: Craig Ringer <ringerc@ringerc.id.au>
1 sibling, 1 reply; 18+ messages in thread
From: Sylvain Mougenot @ 2011-12-14 15:30 UTC (permalink / raw)
To: pgsql-sql
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@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...;
>
> with posts like:
>
> http://archives.postgresql.**org/pgsql-jdbc/2010-10/**msg00131.php<http://archives.postgresql.org...;
> http://archives.postgresql.**org/pgsql-jdbc/2010-10/**msg00077.php<http://archives.postgresql.org...;
>
>
> 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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-14 16:13 David Fetter <david@fetter.org>
parent: Craig Ringer <ringerc@ringerc.id.au>
1 sibling, 2 replies; 18+ messages in thread
From: David Fetter @ 2011-12-14 16:13 UTC (permalink / raw)
To: Craig Ringer <ringerc@ringerc.id.au>; +Cc: Sylvain Mougenot <smougenot@sqli.com>; pgsql-sql
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 00:50 Craig Ringer <ringerc@ringerc.id.au>
parent: Sylvain Mougenot <smougenot@sqli.com>
0 siblings, 0 replies; 18+ messages in thread
From: Craig Ringer @ 2011-12-15 00:50 UTC (permalink / raw)
To: Sylvain Mougenot <smougenot@sqli.com>; +Cc: pgsql-sql
On 12/14/2011 11:30 PM, Sylvain Mougenot wrote:
> 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?
>
I haven't heard of any active work on it recently.
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 03:25 Craig Ringer <ringerc@ringerc.id.au>
parent: David Fetter <david@fetter.org>
1 sibling, 0 replies; 18+ messages in thread
From: Craig Ringer @ 2011-12-15 03:25 UTC (permalink / raw)
To: pgsql-sql
Replied on pgsql-jdbc; please follow the discussion there.
--
Craig Ringer
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 03:26 Craig Ringer <ringerc@ringerc.id.au>
parent: David Fetter <david@fetter.org>
1 sibling, 1 reply; 18+ messages in thread
From: Craig Ringer @ 2011-12-15 03:26 UTC (permalink / raw)
To: David Fetter <david@fetter.org>; +Cc: Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
On 15/12/11 00:13, David Fetter wrote:
>
> 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?
>
I can't currently help with that one. Time permitting I'll see if I can
grab their express editions and find out, but it's going to be hard to
justify doing that on work time as I don't need this functionality, and
personal time is currently insanely busy.
I've popped a question up here:
http://stackoverflow.com/questions/8514725/obtaining-a-java-util-timer-or-equivalent-in-a-javaee-fri...
to see if I can get some broader input on the issue of portable timers.
--
Craig Ringer
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 04:45 Craig Ringer <ringerc@ringerc.id.au>
parent: Craig Ringer <ringerc@ringerc.id.au>
0 siblings, 2 replies; 18+ messages in thread
From: Craig Ringer @ 2011-12-15 04:45 UTC (permalink / raw)
To: David Fetter <david@fetter.org>; +Cc: Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
> I've popped a question up here:
>
>
> http://stackoverflow.com/questions/8514725/obtaining-a-java-util-timer-or-equivalent-in-a-javaee-fri...
>
> to see if I can get some broader input on the issue of portable timers.
... and boy am I glad I did, thanks to Bauke Scholtz (BalusC) on SO.
It looks like we can probably use a ScheduledThreadPoolExecutor safely
from within a Java EE container or servlet container, so long as:
- We never let EE application code that requires EE services - like
servlet code, EJBs, etc - run on its thread(s); and
- We use a ServiceLoader in /META-INF/services to destroy it when the
JDBC driver is unloaded, the war
the JDBC driver is bundled in is undeployed or the app server is stopped;
That should provide the JDBC driver with a suitable timer mechanism.
Perhaps more excitingly, a generic ThreadPoolExecutor can be safely used
within an EE container the same way, potentially allowing the JDBC
driver to use threads for blocking I/O. That'd finally permit a version
of PgConnection.getNotifications() that can be safely invoked without
blocking when SSL is in use!
A driver thread pool could also help permanently fix those occasional
deadlocks that happen due to buffer management issues in the JDBC driver.
I'll try to find time to do some testing and see if I can make this work
or at least bash out a proof of concept.
--
Craig Ringer
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 08:11 =?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= <tivv00@gmail.com>
parent: Craig Ringer <ringerc@ringerc.id.au>
1 sibling, 1 reply; 18+ messages in thread
From: Віталій Тимчишин @ 2011-12-15 08:11 UTC (permalink / raw)
To: Craig Ringer <ringerc@ringerc.id.au>; pgsql-jdbc@postgresql.org
2011/12/15 Craig Ringer <ringerc@ringerc.id.au>
>
> Perhaps more excitingly, a generic ThreadPoolExecutor can be safely used
> within an EE container the same way, potentially allowing the JDBC driver
> to use threads for blocking I/O. That'd finally permit a version of
> PgConnection.getNotifications() that can be safely invoked without blocking
> when SSL is in use!
>
> A driver thread pool could also help permanently fix those occasional
> deadlocks that happen due to buffer management issues in the JDBC driver.
>
> I'll try to find time to do some testing and see if I can make this work
> or at least bash out a proof of concept.
>
> ?
>
How about moving to NIO? Or may be I could try it myself. Can you give me a
class name I need to dig into transport layer?
--
Best regards,
Vitalii Tymchyshyn
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 11:21 Dave Cramer <pg@fastcrypt.com>
parent: =?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= <tivv00@gmail.com>
0 siblings, 0 replies; 18+ messages in thread
From: Dave Cramer @ 2011-12-15 11:21 UTC (permalink / raw)
To: Віталій Тимчишин <tivv00@gmail.com>; +Cc: Craig Ringer <ringerc@ringerc.id.au>; pgsql-jdbc@postgresql.org
I implemented it in the current CVS. Please test
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
2011/12/15 Віталій Тимчишин <tivv00@gmail.com>:
>
>
> 2011/12/15 Craig Ringer <ringerc@ringerc.id.au>
>>
>>
>> Perhaps more excitingly, a generic ThreadPoolExecutor can be safely used
>> within an EE container the same way, potentially allowing the JDBC driver to
>> use threads for blocking I/O. That'd finally permit a version of
>> PgConnection.getNotifications() that can be safely invoked without blocking
>> when SSL is in use!
>>
>> A driver thread pool could also help permanently fix those occasional
>> deadlocks that happen due to buffer management issues in the JDBC driver.
>>
>> I'll try to find time to do some testing and see if I can make this work
>> or at least bash out a proof of concept.
>>
>> ?
>
> How about moving to NIO? Or may be I could try it myself. Can you give me a
> class name I need to dig into transport layer?
>
> --
> Best regards,
> Vitalii Tymchyshyn
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 11:29 Radosław Smogura <rsmogura@softperience.eu>
parent: Craig Ringer <ringerc@ringerc.id.au>
1 sibling, 1 reply; 18+ messages in thread
From: Radosław Smogura @ 2011-12-15 11:29 UTC (permalink / raw)
To: Craig Ringer <ringerc@ringerc.id.au>; +Cc: David Fetter <david@fetter.org>; Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
Long, long time ago I've sent implementation with timers, you need to
search archive If you need this.
Regards,
Radek
On Thu, 15 Dec 2011 12:45:57 +0800, Craig Ringer wrote:
>> I've popped a question up here:
>>
>>
>
> http://stackoverflow.com/questions/8514725/obtaining-a-java-util-timer-or-equivalent-in-a-javaee-fri...
>> [1]
>>
>> to see if I can get some broader input on the issue of portable
>> timers.
>
> ... and boy am I glad I did, thanks to Bauke Scholtz (BalusC) on SO.
>
> It looks like we can probably use a ScheduledThreadPoolExecutor
> safely from within a Java EE container or servlet container, so long
> as:
>
> - We never let EE application code that requires EE services - like
> servlet code, EJBs, etc - run on its thread(s); and
>
> - We use a ServiceLoader in /META-INF/services to destroy it when
> the
> JDBC driver is unloaded, the war
> the JDBC driver is bundled in is undeployed or the app server is
> stopped;
>
> That should provide the JDBC driver with a suitable timer mechanism.
>
> Perhaps more excitingly, a generic ThreadPoolExecutor can be safely
> used within an EE container the same way, potentially allowing the
> JDBC driver to use threads for blocking I/O. That'd finally permit a
> version of PgConnection.getNotifications() that can be safely invoked
> without blocking when SSL is in use!
>
> A driver thread pool could also help permanently fix those
> occasional
> deadlocks that happen due to buffer management issues in the JDBC
> driver.
>
> I'll try to find time to do some testing and see if I can make this
> work or at least bash out a proof of concept.
>
> --
> Craig Ringer
>
>
> Links:
> ------
> [1]
>
> http://stackoverflow.com/questions/8514725/obtaining-a-java-util-timer-or-equivalent-in-a-javaee-fri...
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 14:02 Craig Ringer <ringerc@ringerc.id.au>
parent: Radosław Smogura <rsmogura@softperience.eu>
0 siblings, 3 replies; 18+ messages in thread
From: Craig Ringer @ 2011-12-15 14:02 UTC (permalink / raw)
To: Radosław Smogura <rsmogura@softperience.eu>; +Cc: David Fetter <david@fetter.org>; Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
On 12/15/2011 07:29 PM, Radosław Smogura wrote:
> Long, long time ago I've sent implementation with timers, you need to
> search archive If you need this.
If it was ages ago, you probably used java.util.Timer, right?
java.util.Timer is not suitable for use in a JDBC driver because it
doesn't do any exception handling on the timer thread, it's subject to
congestion on the timer thread, and it offers no way for the driver to
control the timer thread to cleanly shut it down during unload. It's
unusable in app servers and not really a great idea anywhere that needs
to be robust and long-running.
--
Craig Ringer
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 14:17 Dave Cramer <pg@fastcrypt.com>
parent: Craig Ringer <ringerc@ringerc.id.au>
2 siblings, 2 replies; 18+ messages in thread
From: Dave Cramer @ 2011-12-15 14:17 UTC (permalink / raw)
To: Craig Ringer <ringerc@ringerc.id.au>; +Cc: Radosław Smogura <rsmogura@softperience.eu>; David Fetter <david@fetter.org>; Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
Craig,
That is the current implementation. What do you suggest as a more
robust implementation ?
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Thu, Dec 15, 2011 at 9:02 AM, Craig Ringer <ringerc@ringerc.id.au> wrote:
> On 12/15/2011 07:29 PM, Radosław Smogura wrote:
>>
>> Long, long time ago I've sent implementation with timers, you need to
>> search archive If you need this.
>
>
> If it was ages ago, you probably used java.util.Timer, right?
>
> java.util.Timer is not suitable for use in a JDBC driver because it doesn't
> do any exception handling on the timer thread, it's subject to congestion on
> the timer thread, and it offers no way for the driver to control the timer
> thread to cleanly shut it down during unload. It's unusable in app servers
> and not really a great idea anywhere that needs to be robust and
> long-running.
>
> --
> Craig Ringer
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 17:38 Steven Schlansker <stevenschlansker@gmail.com>
parent: Dave Cramer <pg@fastcrypt.com>
1 sibling, 0 replies; 18+ messages in thread
From: Steven Schlansker @ 2011-12-15 17:38 UTC (permalink / raw)
To: Dave Cramer <pg@fastcrypt.com>; +Cc: Craig Ringer <ringerc@ringerc.id.au>; Radosław Smogura <rsmogura@softperience.eu>; David Fetter <david@fetter.org>; Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
java.util.concurrent introduces ScheduledExecutorService, which fixes a lot of the problems with java.util.Timer and introduces more features.
Specifically, it enqueues timed actions and executes them on a thread pool, providing good controls both for controlling individual tasks (canceling) and the entire pool (shutting down cleanly / immediately)
It might be a good fit for implementing timeouts.
On Dec 15, 2011, at 6:17 AM, Dave Cramer wrote:
> Craig,
>
> That is the current implementation. What do you suggest as a more
> robust implementation ?
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
>
> On Thu, Dec 15, 2011 at 9:02 AM, Craig Ringer <ringerc@ringerc.id.au> wrote:
>> On 12/15/2011 07:29 PM, Radosław Smogura wrote:
>>>
>>> Long, long time ago I've sent implementation with timers, you need to
>>> search archive If you need this.
>>
>>
>> If it was ages ago, you probably used java.util.Timer, right?
>>
>> java.util.Timer is not suitable for use in a JDBC driver because it doesn't
>> do any exception handling on the timer thread, it's subject to congestion on
>> the timer thread, and it offers no way for the driver to control the timer
>> thread to cleanly shut it down during unload. It's unusable in app servers
>> and not really a great idea anywhere that needs to be robust and
>> long-running.
>>
>> --
>> Craig Ringer
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 20:48 Radosław Smogura <rsmogura@softperience.eu>
parent: Craig Ringer <ringerc@ringerc.id.au>
2 siblings, 0 replies; 18+ messages in thread
From: Radosław Smogura @ 2011-12-15 20:48 UTC (permalink / raw)
To: Craig Ringer <ringerc@ringerc.id.au>; +Cc: David Fetter <david@fetter.org>; Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
On Thu, 15 Dec 2011 22:02:43 +0800, Craig Ringer wrote:
> On 12/15/2011 07:29 PM, Radosław Smogura wrote:
>> Long, long time ago I've sent implementation with timers, you need
>> to search archive If you need this.
>
> If it was ages ago, you probably used java.util.Timer, right?
>
> java.util.Timer is not suitable for use in a JDBC driver because it
> doesn't do any exception handling on the timer thread, it's subject
> to
> congestion on the timer thread, and it offers no way for the driver
> to
> control the timer thread to cleanly shut it down during unload. It's
> unusable in app servers and not really a great idea anywhere that
> needs to be robust and long-running.
>
> --
> Craig Ringer
Indeed it was Timer with subclassed TimerTask. In any way
implementation was that it was prepared for choosing per connection (and
per connection is used during normal execution), per data source, or per
class loader (this is used in case of data sources).
For shutting down implementation is clear thread associated with Timer
will go away if no more tasks are scheduled and there is no more
references to Timer. Demonizing timer is quite enough.
From implementation if I recall well I used a little bit different
concept to create "atomic" operations chain for query executor protected
in addition with timer - and I think this concept was fully realized.
Regards,
Radosław Smogura
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-15 20:49 Radosław Smogura <rsmogura@softperience.eu>
parent: Craig Ringer <ringerc@ringerc.id.au>
2 siblings, 0 replies; 18+ messages in thread
From: Radosław Smogura @ 2011-12-15 20:49 UTC (permalink / raw)
To: Craig Ringer <ringerc@ringerc.id.au>; +Cc: David Fetter <david@fetter.org>; Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
On Thu, 15 Dec 2011 22:02:43 +0800, Craig Ringer wrote:
> On 12/15/2011 07:29 PM, Radosław Smogura wrote:
>> Long, long time ago I've sent implementation with timers, you need
>> to search archive If you need this.
>
> If it was ages ago, you probably used java.util.Timer, right?
>
> java.util.Timer is not suitable for use in a JDBC driver because it
> doesn't do any exception handling on the timer thread, it's subject
> to
> congestion on the timer thread, and it offers no way for the driver
> to
> control the timer thread to cleanly shut it down during unload. It's
> unusable in app servers and not really a great idea anywhere that
> needs to be robust and long-running.
>
> --
> Craig Ringer
Indeed it was Timer with subclassed TimerTask. In any way
implementation was that it was prepared for choosing per connection (and
per connection is used during normal execution), per data source, or per
class loader (this is used in case of data sources).
For shutting down implementation is clear thread associated with Timer
will go away if no more tasks are scheduled and there is no more
references to Timer. Demonizing timer is quite enough.
From implementation if I recall well I used a little bit different
concept to create "atomic" operations chain for query executor protected
in addition with timer - and I think this concept was fully realized.
Regards,
Radosław Smogura
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?
@ 2011-12-16 03:57 Craig Ringer <ringerc@ringerc.id.au>
parent: Dave Cramer <pg@fastcrypt.com>
1 sibling, 0 replies; 18+ messages in thread
From: Craig Ringer @ 2011-12-16 03:57 UTC (permalink / raw)
To: Dave Cramer <pg@fastcrypt.com>; +Cc: Radosław Smogura <rsmogura@softperience.eu>; David Fetter <david@fetter.org>; Sylvain Mougenot <smougenot@sqli.com>; pgsql-jdbc@postgresql.org
On 15/12/2011 10:17 PM, Dave Cramer wrote:
> Craig,
>
> That is the current implementation. What do you suggest as a more
> robust implementation ?
A java.util.concurrent.ScheduledThreadPoolExecutor
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/package-summary.html
See discussion:
http://stackoverflow.com/questions/8514725/obtaining-a-java-util-timer-or-equivalent-in-a-javaee-fri...
I'd just skip building statementTimeout support for the JDBC3 driver,
avoiding the issue with the JDK 1.5 requirement that way.
--
Craig Ringer
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2011-12-16 03:57 UTC | newest]
Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-12-14 13:29 JDBC Statement.setQueryTimeout : is there plan to implement this? Sylvain Mougenot <smougenot@sqli.com>
2011-12-14 13:42 ` Craig Ringer <ringerc@ringerc.id.au>
2011-12-14 14:01 ` Craig Ringer <ringerc@ringerc.id.au>
2011-12-14 15:30 ` Sylvain Mougenot <smougenot@sqli.com>
2011-12-15 00:50 ` Craig Ringer <ringerc@ringerc.id.au>
2011-12-14 16:13 ` David Fetter <david@fetter.org>
2011-12-15 03:25 ` Craig Ringer <ringerc@ringerc.id.au>
2011-12-15 03:26 ` Craig Ringer <ringerc@ringerc.id.au>
2011-12-15 04:45 ` Craig Ringer <ringerc@ringerc.id.au>
2011-12-15 08:11 ` =?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= <tivv00@gmail.com>
2011-12-15 11:21 ` Dave Cramer <pg@fastcrypt.com>
2011-12-15 11:29 ` Radosław Smogura <rsmogura@softperience.eu>
2011-12-15 14:02 ` Craig Ringer <ringerc@ringerc.id.au>
2011-12-15 14:17 ` Dave Cramer <pg@fastcrypt.com>
2011-12-15 17:38 ` Steven Schlansker <stevenschlansker@gmail.com>
2011-12-16 03:57 ` Craig Ringer <ringerc@ringerc.id.au>
2011-12-15 20:48 ` Radosław Smogura <rsmogura@softperience.eu>
2011-12-15 20:49 ` Radosław Smogura <rsmogura@softperience.eu>
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