Re: A new JDBC driver...

On 03/15/2013 01:15 PM, Kevin Wooten wrote:
> After a bit of messing around I finally settled on the much maligned
> "finalizer" to kill the connection if it's abandoned.
Oh, and re finalizers:

https://www.securecoding.cert.org/confluence/display/java/MET12-J.+Do+not+use+finalizers

In particular, these points:

* There is no fixed time at which finalizers must be executed because
this depends on the JVM. The only guarantee is that any finalizer
method that executes will do so sometime after the associated object
has become unreachable (detected during the first cycle of garbage
collection) and sometime before the garbage collector reclaims the
associated object's storage (during the garbage collector's second
cycle). Execution of an object's finalizer may be delayed for
an /arbitrarily/ long time after the object becomes unreachable.
Consequently, invoking time-critical functionality such as closing
file handles in an object's |finalize()| method is problematic.

* The JVM may terminate without invoking the finalizer on some or all
unreachable objects. Consequently, attempts to update critical
persistent state from finalizer methods can fail without warning.
Similarly, Java lacks any guarantee that finalizers will execute on
process termination. Methods such
as |System.gc()|, |System.runFinalization()|, |System.runFinalizersOnExit()|,
and |Runtime.runFinalizersOnExit()| either lack such guarantees or
have been deprecated because of lack of safety and potential for
deadlock.

* According to the /Java Language Specification/, §12.6.2, "Finalizer
Invocations are Not Ordered"
<http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.6.2> [JLS
2005
<https://www.securecoding.cert.org/confluence/display/java/AA.+References#AA.References-JLS05>]:

The Java programming language imposes no ordering
on |finalize()| method calls. Finalizers [of different objects]
may be called in any order, or even concurrently.

One consequence is that slow-running finalizers can delay execution
of other finalizers in the queue. Further, the lack of guaranteed
ordering can lead to substantial difficulty in maintaining desired
program invariants
<https://www.securecoding.cert.org/confluence/display/java/BB.+Glossary#BB.Glossary-invariant>.
* Use of finalizers can introduce synchronization issues even when the
remainder of the program is single-threaded.
The |finalize()| methods are invoked by the garbage collector from
one or more threads of its choice; these threads are typically
distinct from the |main()| thread, although this property is not
guaranteed. When a finalizer is necessary, any required cleanup data
structures must be protected from concurrent access. See the JavaOne
presentation by Hans J. Boehm [Boehm 2005
<https://www.securecoding.cert.org/confluence/display/java/AA.+References#AA.References-Boehm05>]
for additional information.

In particular I would be concerned that a thread refcounting system
would be subject to ordering problems or deadlocks introduced by
attempts to introduce fixes for ordering problems.

I really need to look into how other JDBC drivers handle these issues;
it's not like this is a new problem.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services