Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 53E97CBE9BC for ; Thu, 15 Dec 2011 00:46:19 -0400 (AST) Received: from mail-yw0-f46.google.com ([209.85.213.46]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Rb3Cz-0007n2-77 for pgsql-jdbc@postgresql.org; Thu, 15 Dec 2011 04:46:19 +0000 Received: by yhr47 with SMTP id 47so1928361yhr.19 for ; Wed, 14 Dec 2011 20:46:03 -0800 (PST) Received: by 10.236.178.71 with SMTP id e47mr2170591yhm.66.1323924363293; Wed, 14 Dec 2011 20:46:03 -0800 (PST) Received: from [10.0.0.53] (office1.postnewspapers.com.au. [150.101.171.128]) by mx.google.com with ESMTPS id 7sm6791919anz.18.2011.12.14.20.46.00 (version=SSLv3 cipher=OTHER); Wed, 14 Dec 2011 20:46:02 -0800 (PST) Message-ID: <4EE97B85.50909@ringerc.id.au> Date: Thu, 15 Dec 2011 12:45:57 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: David Fetter CC: Sylvain Mougenot , pgsql-jdbc@postgresql.org Subject: Re: [SQL] JDBC Statement.setQueryTimeout : is there plan to implement this? References: <4EE8AC41.2040505@ringerc.id.au> <20111214161349.GA31176@fetter.org> <4EE968FF.5010604@ringerc.id.au> In-Reply-To: <4EE968FF.5010604@ringerc.id.au> Content-Type: multipart/alternative; boundary="------------010201000808030709040809" X-Pg-Spam-Score: -1.2 (-) X-Archive-Number: 201112/57 X-Sequence-Number: 22511 This is a multi-part message in MIME format. --------------010201000808030709040809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > 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 --------------010201000808030709040809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

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
--------------010201000808030709040809--