File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Websphere and the fly likes Syncronisation of WAS servers in a cluster Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Websphere
Bookmark "Syncronisation of WAS servers in a cluster" Watch "Syncronisation of WAS servers in a cluster" New topic

Syncronisation of WAS servers in a cluster

Hemant Bhasin

Joined: Nov 20, 2003
Posts: 6
In a WAS cluster, are the memory contents replicated across the WAS servers and syncronised ?
e.g for a 2 node WAS cluster, if a entity Bean EB1 is accessing to row1 on server1 and is in pool. Then is the EB1 replicated to server2 also.
If not, does WAS ensure that any access to EB1 (for row1) on server2 is redirected to server1
Tony Liu

Joined: Jun 08, 2002
Posts: 1
Which version you are using? For version 4, seems that it's not possible to share memory contents except using persistent session.
And according to the redbook, "After an application server is selected, client requests for that entity bean are forwarded to it for the duration of the transaction." So if the access is within the same transaction, it won't redirect to another server I think.
Hemant Bhasin

Joined: Nov 20, 2003
Posts: 6
I am using WAS 5.0.
What would have in case of separate session and transaction.
If there are 2 different application clients.
Both are trying to access the same EB (ie Entity bean for the same row)
As per the load balance scheme both get connected to different WAS servers (in the WAS cluster). In such a scenario, would only one copy of EB be there, in that case all request for the that EB would have to be routed to the same server.
If that is not done by the WAS cluster, would the cluster replicate all EB on all servers in the cluster
Kyle Brown
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
First of all, the only type of beans that have state are Entity beans and Stateful session beans. Stateful Session beans are not load-balanced. Requests from a stateful session bean client will always go to the same stateful session bean instance so long as the client handle is in existence. However, this means that if you want a stateful session bean to survive across multiple web requests (which can be load balanced) then you must place the stateful session bean handle in the HttpSession.
Entity beans also have state, but normally the state is NOT maintained across transaction boundaries. This is called "Option C" (or "Option B", which works nearly the same)entity caching and is the default. If you want the values of an entity to be stored across transactions, then you use "Option A" caching. However, this is not recommended for use with clustering because then the values of the beans can drift over time from the corresponding values in the database.
So, the moral of the story is, if you follow best practices and use Stateless session beans and Option C caching on your Entity beans, then you never have to worry about this.
BTW, I believe I cover this in the best practices section of my book.

Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at for other WebSphere information.
I agree. Here's the link:
subject: Syncronisation of WAS servers in a cluster
It's not a secret anymore!