EJB design: Propogation of changes in a singleton across JVMs

  1. Hi
      How can i propogate changes to singleton objects across JVMs in a cluster.
      For example :
      I have a singleton object "ApplicationSettings" which gets created on each JVM in a cluster.Lets say if one singleton object in one JVM gets changed ; how can I sync the singleton in other JVMS. (Essentially an object cache in a clustered environment)
    P.S: is this the right strategy for distributed caching ; as the JNDI cluster binding of non RMI objects in weblogic server comes with its own sets of problems.
  2. I can think of two solutions here .

    1. Use JMS to pass the information to other members of cluster
    2. Make the changes persistent and let the info be gathered by other members ...
  3. People often solve this problem using JMS pub/subscribe to communicate between VMs.

    One option is when accessing cached data, the cache manager (in this case the singleton) checks for updates on the queue before returning the cache data.

    Message Driven Beans can also be used to update cached information. This would be better as updates would be handled when the arrive.

    Two years ago at Java One there was a cool session on this. I can't remember if it was some guy from Sybase or TheServerSide.com who gave it.

  4. Thanks Guys
    JMS seems to be a good solution ; tho i wont go for a persistent type cache ; as its expensive updating object states.
  5. Depends on your requirements. Do you need updates to occur immediately and have perfect synchronization throughout the cluster, then a simple RMI remote object is probably your best choice. The object will be pinned to one particular server, and will be accessed by all other servers via its remote interface. You will need this level of synchronization if you were implementing pessimistic locking of objects across VM's.

    Otherwise, if you don't need perfect synchronization then JMS is the ideal solution. The updates are asynchronous and won't happen simultaneously on all servers at the same time.