Обсуждение: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this?

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-friendly-way-that-works-on

to see if I can get some broader input on the issue of portable timers.



--
Craig Ringer

I've popped a question up here:

http://stackoverflow.com/questions/8514725/obtaining-a-java-util-timer-or-equivalent-in-a-javaee-friendly-way-that-works-on

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

--
Best regards,
 Vitalii Tymchyshyn

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

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-friendly-way-that-works-on
>> [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-friendly-way-that-works-on

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

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

java.util.concurrent introduces ScheduledExecutorService, which fixes a lot of the problems with java.util.Timer and
introducesmore features. 

Specifically, it enqueues timed actions and executes them on a thread pool, providing good controls both for
controllingindividual 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

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

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

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-friendly-way-that-works-on

I'd just skip building statementTimeout support for the JDBC3 driver,
avoiding the issue with the JDK 1.5 requirement that way.

--
Craig Ringer