This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
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
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.
Joined: Nov 20, 2003
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
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