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.
- Posted by: Jaganath SR
- Posted on: January 30 2003 02:00 EST
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.
- Sharing data across session beans by Rob Misek on January 30 2003 13:20 EST
- Sharing data across session beans by PThakur Thakur on January 30 2003 16:09 EST
- JNDI, stateful beans by Alex Pisarev on January 31 2003 03:11 EST
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.
Coherence: Easily share live data across a cluster!
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
I hope this will work.
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.
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.
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.
Why do not you use single ton class to share your Hashtable object.
Thanks. Thats what we did finally.