Static Class JMS Listener

Question

I am designing an EJB component (MessageDrivenBean) that requires
dynamic ("hot") configuration changes. As such, the bean must be
notified somehow of configuration changes in the DB (rather than have
to poll the DB for changes at every method call).
I'm thinking of implementing this functionality using a static class
instance (singleton) that is shared between the multiple instances of
the bean. This static instance would listen on a JMS topic for
configuration change events and update its internal cache accordingly
(by getting the configuration information from the DB). The beans
would then access this in-memory static instance everytime they need
configuration info instead of polling the database. By using the JMS
topic, I guarantee that clustered instances of Weblogic will all be
notified of the database changes (each instance would have its own
"cache" singleton).
I'm pretty sure all of this will work, but I'm equally sure that I'm
violating some EJB rules. Singletons and JMS listeners are generally
discouraged. Are there any alternatives to this design?

Answer 1

Hi Joost,
This all seems to be pretty complicated. Not to mention that you can not
guarantee that members of a cluster will be notified simultaneously.
Why don't you want using the database?
"Joost Ouwerkerk" <[email protected]> wrote in message
news:[email protected]..
I am designing an EJB component (MessageDrivenBean) that requires
dynamic ("hot") configuration changes. As such, the bean must be
notified somehow of configuration changes in the DB (rather than have
to poll the DB for changes at every method call).
I'm thinking of implementing this functionality using a static class
instance (singleton) that is shared between the multiple instances of
the bean. This static instance would listen on a JMS topic for
configuration change events and update its internal cache accordingly
(by getting the configuration information from the DB). The beans
would then access this in-memory static instance everytime they need
configuration info instead of polling the database. By using the JMS
topic, I guarantee that clustered instances of Weblogic will all be
notified of the database changes (each instance would have its own
"cache" singleton).
I'm pretty sure all of this will work, but I'm equally sure that I'm
violating some EJB rules. Singletons and JMS listeners are generally
discouraged. Are there any alternatives to this design?Regards,
Slava Imeshev