-
Updating cached data held in a stateful bean (3 messages)
- Posted by: raja rajendran
- Posted on: January 12 2007 21:28 EST
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.Threaded Messages (3)
- Re: Updating cached data held in a stateful bean by Vinant Pandey on January 13 2007 00:36 EST
- Re: Updating cached data held in a stateful bean by raja rajendran on January 16 2007 11:51 EST
- Re: Updating cached data held in a stateful bean by shreenee josh on February 05 2007 04:18 EST
-
Re: Updating cached data held in a stateful bean[ Go to top ]
- Posted by: Vinant Pandey
- Posted on: January 13 2007 00:36 EST
- in response to raja rajendran
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 PandeyHello 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. -
Re: Updating cached data held in a stateful bean[ Go to top ]
- Posted by: raja rajendran
- Posted on: January 16 2007 11:51 EST
- in response to Vinant Pandey
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. -
Re: Updating cached data held in a stateful bean[ Go to top ]
- Posted by: shreenee josh
- Posted on: February 05 2007 04:18 EST
- in response to raja rajendran
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