Greg,
 
Only Topic is multicast by specification.  To keep all objects on the network updated, simply have any object that is subject to caching to publish the appropriate change-Topic message and those that are interested in the change subscribe to that change-Topic. There is basically two ways to propagate the change: 1) use a text message containing the database reference id so that the correct row can be refetched (IO expense) or 2) use an object message containing a DataObjectChangeEvent object with the old and new values so that the subscriber can determine which of its values change by check the old value (no IO expense).  Remember all object of a class will be subscribers to the change message, which means that a subscriber must be able to determine readily (simply) whether the received message needs to be processed or not.
 
Dave
-----Original Message-----
From: Greg Matthews [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 24, 2001 3:15 AM
To: Orion-Interest
Subject: JMS: Queue or Topic multicast?

dear all,
 
are either of the Queue or Topic parts of the JMS multicast? i.e. once one subscriber pulls the message off the queue, can other subscribers see the message?
 
since each of our clustered servers cache some info, i was thinking that a half-reasonable way of dealing with some stuff being updated on one server would be for the updated server to fire an "i've been updated" message, causing the other servers to refresh their cache.
 
i know i could probably look at entity beans, etc, but would just like an answer to my question if anyone knows.
 
thanks very much,
greg.

Reply via email to