Re: JDBC gripe list

I thought I would add my comments regarding Timer and TimerTask.
The following comments are taken from the Java docs for Timer.

<JavaDoc snipet...>
Corresponding to each <tt>Timer</tt> object is a single background
thread that is used to execute all of the timer's tasks, sequentially.
Timer tasks should complete quickly. If a timer task takes excessive time
to complete, it "hogs" the timer's task execution thread. This can, in
turn, delay the execution of subsequent tasks, which may "bunch up" and
execute in rapid succession when (and if) the offending task finally
completes.
</JavaDoc snipet...>

What this means is that if your TimerTask execution time is unknown or not
quantifiable then you cannot reliably use a TimerTask without creating a
worker thread to do the work, otherwise you break the reliability of the
time between events. Effectively you need a second thread to do the work!
In short you are better to create your own single thread to manage such
events.

I already have a lot of experience with a modified PosgreSQL 7.4 driver and
notification threads. Our company has been using it since 2005.

The most reliable approach we came up with is:

1) Modify the driver such that you can synchronize separately on
PGStream.pg_input
and PGStream.pg_output.
We did this such that to synchronize on pg_input you should first
synchronize on pg_output. This is a programming procedure that cannot be
enforced by the language or compilers. This procedure ensures no synchronize
deadlocks. The only code that does not adhere to this procedure is the
notification thread.

2) Create a single notification thread.
Basic processing logic is as follows;
    i) Start process loop.
    ii) Synchronize on PGStream.pg_input.
    iii) stream.Mark(1).
    iv) stream.ReceiveChar().
    v) is Character notification? Yes - get notification data, No - reset
        stream.
    vi) exit synchronize on PGStream.pg_input.
    vii) If have notification data - do fire notification event, else wait x
        time.
    viii) restart process loop.

If you would like me to modify the current driver to show how this works I
am willing to do so.
However it still does not solve the thread instantiation problem.

Regards
Donald

----- Original Message -----
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Vitalii Tymchyshyn" <tivv00@gmail.com>
Cc: "Dave Cramer" <pg@fastcrypt.com>; "List" <pgsql-jdbc@postgresql.org>;
"Craig Ringer" <craig@postnewspapers.com.au>
Sent: Tuesday, March 29, 2011 4:55 PM
Subject: Re: [JDBC] JDBC gripe list


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