Scot P. Floess wrote:
> I was wondering, have y'all considered using JMS to broadcast after manipulating the database? Or is the requirement
specificallyfor the DB to notify?
The requirement is that notify-commands cause a callback method to
be called.
JMS might be a solution for some cases, but not all Java applications
run in an environment with JMS.
In addition, JMS is limited to Java whereas notify can be executed by
any DB client or even by the database itself (trigger).
Let me provide an example:
Imagine a database with a table for user privileges. Clients might want
to cache that table in order to hold the number of concurrent connections
low. However, it is mandatory that clients are informed about changes
in that table. A trigger that executes a notify on inserts/updates/deletes
on that table would inform the clients about the change. (No matter
who did the change - it could even be through the psql interface.)
JMS and an application server architecture are definitely the solution to
choose for a big number of applications but there are also many scenarios
where a "notify-callback" would be handy.
Kind regards,
Johann Uhrmann
P.S.:
Using the "notify-callback" functionality in a J2EE environment would not
be allowed because it is similar to the creation of new threads which is
definitely not allowed for Enterprise Beans.
But that does not mean that the driver itself could not be used by an
j2ee server - it is merely that callback registration which would be
off limits.
--
Johann Uhrmann
xpecto AG | Lindenstrasse 81 | D-84030 Ergolding
Telefon: 0700 xpecto 00 (0700 973286 00)
Telefax: 0700 xpecto 10 (0700 973286 10)
Internet: http://www.xpecto.com