Re: JDBC gripe list

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Vitalii Tymchyshyn" <tivv00(at)gmail(dot)com>
Cc: "Dave Cramer" <pg(at)fastcrypt(dot)com>, "List" <pgsql-jdbc(at)postgresql(dot)org>, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>
Subject: Re: JDBC gripe list
Date: 2011-03-29 15:55:57
Message-ID: 4D91BABD020000250003BEA3@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Vitalii Tymchyshyn <tivv00(at)gmail(dot)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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Quartz 2011-03-29 19:29:51 Re: JDBC gripe list
Previous Message MauMau 2011-03-29 15:21:58 Re: JDBC gripe list