Re: JDBC gripe list - Mailing list pgsql-jdbc

From Kevin Grittner
Subject Re: JDBC gripe list
Date
Msg-id 4D91BABD020000250003BEA3@gw.wicourts.gov
Whole thread Raw
In response to Re: JDBC gripe list  (Vitalii Tymchyshyn <tivv00@gmail.com>)
Responses Re: JDBC gripe list  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-jdbc
Vitalii Tymchyshyn <tivv00@gmail.com> wrote:

> 1) Thread creation may be prohibited by SecurityManager. I'd
> expect J2EE containers prohibit such a thing since EJBs are
> prohibited to create it's own threads.

I've never used EJBs, as the description of the technology sounded
awful to me up front.  If they prohibit this, it would be a problem.
Can the security policy be adjusted to allow this specific
exception without too much pain?

> 2) Postgresql driver may be located in "global" classloader, but
> used from "local" one. I am not sure, which classloader will new
> thread receive. If it will be "local" one, this will mean global
> driver will hold reference to classloader (application) from which
> it were used for the first time.

I don't think we would have a problem here if we cancel the Timer
when the last connection closes.  My recollection from working on
our own framework is that an object is blocked from garbage
collection as long as there is a chain of references to it from an
active thread where all references in that chain are stronger than a
WeakReference.  A Timer's thread obviously needs strong references
both its own classloader and all objects queued for execution.
Since Timer.cancel() gracefully stops its worker thread, it would no
longer prevent cleanup.

-Kevin

pgsql-jdbc by date:

Previous
From: "MauMau"
Date:
Subject: Re: JDBC gripe list
Next
From: Quartz
Date:
Subject: Re: JDBC gripe list