Updating cached data held in a stateful bean

Discussions

EJB design: Updating cached data held in a stateful bean

  1. Updating cached data held in a stateful bean (3 messages)

    Hello all, I have a requirement where a stateful bean holds session data (caching) on behalf of the client. This cached data needs to be updated using data change notifications received from an external source (and not from the bean's client). Is there a way to accomplish this elegantly? I did some investigation about using JMS to receive change notifications but a stateful bean cannot receive JMS notifications asynchronously. A mechanism to synchronously poll for the JMS notifications periodically is not viable, using the J2EE 1.5 timer service, as the timer service does not apply to stateful beans. From the J2EE spec, multiple callers to a stateful bean instance are allowed only if the calls can be serialized. If multiple callers make method calls to the instance concurrently, the container will raise an exception. From this, it seems there is no safe mechanism to inject the data change notifications into the stateful bean. Any help will be appreciated. thanks for your time. Raj.
  2. To rephrase your question. "You want to update a stateful session bean from multiple clients" .... My answer is a question .....why not use stateless session bean to handle this ? ...or have a stateless session bean as an interface to a stateful session bean to handle the changes ? -Vinant Pandey
    Hello all,

    I have a requirement where a stateful bean holds session data (caching) on behalf of the client. This cached data needs to be updated using data change notifications received from an external source (and not from the bean's client). Is there a way to accomplish this elegantly?

    I did some investigation about using JMS to receive change notifications but a stateful bean cannot receive JMS notifications asynchronously. A mechanism to synchronously poll for the JMS notifications periodically is not viable, using the J2EE 1.5 timer service, as the timer service does not apply to stateful beans.

    From the J2EE spec, multiple callers to a stateful bean instance are allowed only if the calls can be serialized. If multiple callers make method calls to the instance concurrently, the container will raise an exception. From this, it seems there is no safe mechanism to inject the data change notifications into the stateful bean.

    Any help will be appreciated.

    thanks for your time.
    Raj.
  3. Vinat, Yes, it is a multiple caller issue but the callers are not located in the same JVM. And I am not sure how your suggestion of calling it using a SLSB will help, as the SFSB methods can still be called concurrently. One possible solution, to ensure that the SFSB methods are not invoked simultaneously by the callers, is to use a synchronization mechanism that works across multiple JVMs. Does such a service exist? Perhaps implemented using a database or a distributed memory cache? Any other alternatives? thanks Raj.
  4. I may sound weired but in my opinion this whole requirement can be implemented only by decoupling the session data from session bean instances. 1. Prepare a centralized session data repository where data can be stored for a unique session IDs. It gives services for updating the synchying up the internal data across the sessions. 2. Every session bean will hold handle to their data stored in the repos. 3. Behind the scene SLSB backed by MDB can performing synch up job. 4. SFSB can act normally by getting / updating data directly from this repos. Any comments?? shrini