Session

[Mary Cole]

Hi all,

I want to know how a session is shared for a particular client in a clusered envi.
The client requests need not haveto go to the same App server or webserver every time....so how is the session data carried out? Pls describe in detail

[Valentin Tanase]

Hi Mary,

All the clustering strategy I�m referring is from WebLogic. Different container could implement clustering in a different way and other people might like speaking about that as well.
First of all, the clustering strategy for web application is much different than the clustering strategy for RMI-based application (like EJBs). Is my understanding that you are interested to find out how the HttpSession objects are clustered.
First of all there are different strategies for failing over the HttpSession objects in a clustered environment: using an underlying RDBMS or using the in-memory replication, which is actually the most popular one. If the RDBMS strategy is quite intuitive (the server instances uses a RDBMS to refresh/save the session data) the in-memory replication is a little bit less intuitive. With this approach WebLogic uses a primary-secondary replication scheme, where two different server instances have the same copy of the HttpSession object. They use ip-multicast technology in order to keep the data in sync (please remark that the session object is not replicated within every instance in the cluster). If the primary instance fails, the secondary becomes primary and WL will pick up another secondary. When an http client creates a session, the server instance that gets the request will first create the session object and send a copy of this object to another instance in the cluster. Secondly it will encode the addresses of the primary and secondary instances in the session ID and will send the request back to the client (simple isn�t it?). The question that remained to be answered is how the server implements the routing algorithm?
Well there are two mechanisms that WL uses for that. One is accomplished employing a hardware load balancer, while the second and most intuitive one is to use a Web server plug-in that proxy(s) requests from the Web server to the WL cluster. In this case when the plug-in receives a request from the Web server, it looks for the session Id associated with the request. If the request doesn�t have a session Id it will forward the request to the next available instance in the cluster following a round-robin algorithm. Otherwise the plug-in will get the address of primary and secondary from the session and will (always) try to forward the request to the primary instance. If the primary is down it will forward the request to the secondary, etc.
The story is even more complex for EJB-clustering and that is achieved using cluster-aware (or replica-aware) stubs. But I�ll stop here for now hopping that I provided you the amount of details you�ve expected.
Regards.

[Dave Clark]

interesting information on WebLogic HttpSession failover - WebSphere implements things in pretty much the exact same way!

WebSphere gives you a few options -
1. no HttpSession fail-over
2. persist HttpSession data to an RDBMS - use the JSessionID cookie as a primary key. If you need to fail-over to another WAS instance, if the HttpSession can't be found in memory, it'll look up the session info from the DB using the JSessionID
3. 'in-memory replication' - a WAS to WAS session data replication mechanism similar to that described for WebLogic above. WebSphere lets you also set up 'replication domains' which allow you to have either peer-to-peer repication for every instance in the cluster, or to set up dedicated session servers and WAS session-data clients.

cheers,

Dave.

[Mary Cole]

Thx a lot guys....now i got the reqd info

Can you explain the ejb clustering too...

[Valentin Tanase]

I might start reminding you that programmers needs to first look up the bean�s home interface into the JNDI in order to get a reference to the bean�s remote interface. WebLogic will cluster all of these : jndi, home interface and remote interface. The server provides a cluster-wide jndi namespace, where each server maintains its own copy of the cluster-wide (or global) jndi. Changes to the global jndi are propagated to each server using the IP-multicast protocol. This is the mean by which WebLogic achieves location transparency: programmers never know to which server in the cluster they are actually connected in order to look up the home interface.
The remote interface is nothing but a client stub for proxying RMI request to the server stub. In a clustered environment this stub (known as a cluster-aware stub, or replica-aware stub) maintains a list of all servers in the cluster. If a server goes down, it is removed from the stub�s list, until the server will start up again. By default the stub uses a round-robin algorithm in order to forward requests to the next server instance in the cluster. Generally soaking this would apply to every RMI object deployed in a clustered environment.
The clustering mechanism is little bit different for each type of enterprise bean. For SFSB(s), WebLogic uses the same in-memory replication logic as for replicating the HttpSession objects. Therefore the stub will maintain only the address of the primary and secondary instances and won�t care much about all other servers in the clusters (unless the primary goes down and a new primary is picked, etc).
For the SLSB(s) WebLogic uses the mechanism explained above. However there is one more difference: the methods declared in the home interface stub are idempotent (the idempotent behavior could be enforced through deployment descriptor flags, or by runnining the rmic compiler passing the right parameters, etc). All other types of home interfaces are not idempotent.
Entity beans are also little bit different, because these stubs use a �sticky� routing algorithm. This means that the server will do everything it can in order to route client requests to the same server instance in the cluster. The reason behind this is mainly for improving the caching capabilities of the server and to reduce transaction propagation across the instances in the cluster.

[Mary Cole]

Thx Tanase ......i really appreciate it