Обсуждение: Asynchronous notifications

Hi hackers,
    I've dived into the jdbc QueryExecutor code to see how Notifications
are handled. Notifications are handled into the execute() method. In
this method, return from pg_stream is read after SendQuery() method is
called. My quite is quite "architectural". I would like to know the
reason that makes the final user to perform a query to get notifications
from the server. My question is directly linked to my problem : I would
like to avoid in my client code to have a thread executing (so sending
packets) SQL void string commands each n seconds in order to notify
observers or other classes. So do you think it is possible do have a
solution with pg JDBC driver? How can I do this? Does  JDBC conformance
tests does allow this?

Thanks in advance!
--
Jean-Christophe Arnu (arnu {at,arobase} paratronic {dot,point} fr

On Thu, 26 Feb 2004, Jean-Christophe ARNU wrote:

> Hi hackers,
>     I've dived into the jdbc QueryExecutor code to see how Notifications
> are handled. Notifications are handled into the execute() method. In
> this method, return from pg_stream is read after SendQuery() method is
> called. My quite is quite "architectural". I would like to know the
> reason that makes the final user to perform a query to get notifications
> from the server. My question is directly linked to my problem : I would
> like to avoid in my client code to have a thread executing (so sending
> packets) SQL void string commands each n seconds in order to notify
> observers or other classes. So do you think it is possible do have a
> solution with pg JDBC driver? How can I do this? Does  JDBC conformance
> tests does allow this?
>

The notifications cannot be received without querying the server.  The
only way the driver could handle this would be to implement the polling
loop that you are currently doing now.  This is really something the
application should do and not the driver.

Someone else has advocated registering a callback with the driver for a
cleaner interface to handle notifications which may have some merit, but
it doesn't solve the polling problem and introduces another set of issues
regarding either thread safety or corrupting the PGStream object or
deadlocking.

http://gborg.postgresql.org/project/pgjdbc/bugs/bugupdate.php?559


Kris Jurka