Sharing data across session beans

Discussions

EJB design: Sharing data across session beans

  1. Sharing data across session beans (7 messages)

    I have an application which makes async calls on a bean. The bean delegates the business logic to some other bean, but immediately returns with a request id to the client application. After processing the business logic, the client needs to be called back with the data it passed along with the results of the execution of the request. I need to store the request id along with the data the client passed in a HashMap. My problem is to persist the data that client passed. Im in a situation where I cannot use database as it will be unnecessrily serializing a lot of objects.

    Someone suggested using an entity bean which writes to a hashtable (which is a static member of the entity bean) instead of a db. But the pblm is what will happen if the entity bean is passivated?

    What is the practical way to share a hashtable across multiple SLB instances?

    Any suggestion will be greatly appreciated.

    Thanks,
    Jaganath

    Threaded Messages (7)

  2. Sharing data across session beans[ Go to top ]

    Hi Jaganath,

    I would suggest you take a look at Tangosol's Coherence product. It will allow you to share data across session beans, along with across a cluster (complete with cluster-wide locking and event notification). It just happens to provide a java.util.Map interface for easy pluggability.

    Later,
    Rob Misek
    http://www.tangosol.com
    Coherence: Easily share live data across a cluster!
  3. Sharing data across session beans[ Go to top ]

    After going through your scenario basically u want to share data acroos session beans so for that definitely u need to cache them and do the cluster. I suggest you to use apached caching frame work and incoprorate the application server clustering mechanism. The link for apache caching framework is
    http://jakarta.apache.org/turbine/jcs/

    I hope this will work.

    pankaj
  4. Further to my last reply you can cache your client information and client data in Context object. So it can be shared among all the session bean also application server clustering mechanism will take care of replication of client's data object. I think this would be better approach for you scenario.

    So do reply me.
  5. JNDI, stateful beans[ Go to top ]

    The ocean of possibilites...

    1. Why don't you bind your HashMap to JNDI? No problems with cluster and cell replications.
    2. Why don't you put your HashMap into StatefulSession bean? You can easily use it to share information between your SLSB in case if you don't call it from two SLSB's simultaneously (you can always synchronize access to your SFSB to sort it out). If you still care about clusters, most of the appservers can do SFSB replications.

    Alex
  6. JNDI, stateful beans[ Go to top ]

    Thanks for the reply, Alex
    But my problem is there will be a frequent update of the hashtable for every client call. For example, when a client calls with a request, the processing will result in a status update of atleast 4 times. Using JNDI will increase the network traffic heavily.

    The request statuses are updated from another network entity, which communicates with my application using JMS. This wakes up an MDB which updates the hashtable. Im not very sure how I can use a Stateful bean in this scenario.

    jaganath
  7. JNDI, stateful beans[ Go to top ]

    Why do not you use single ton class to share your Hashtable object.
  8. JNDI, stateful beans[ Go to top ]

    Thanks. Thats what we did finally.