Remember from the previous chapter, we talked briefly about distributed web apps, where the pieces of the app might be replicated across multiple nodes in the network. In a clustered environment, the Container might do load-balancing by taking client requests and sending them out to JVMs (which may or may not be on different physical boxes, but that doesn’t matter to us). The point is, the app is in multiple places.

That means each time the same client makes a request, the request could end up going to a different instance of the same servlet. In other words, request A for Servlet A could happen on one VM, and request B for Servlet A could end up on a different VM. So the question is, what happens to things like ServletContext, ServletConfig, and HttpSession objects?

Simple answer, important implications:

Only HttpSession objects (and their attributes) move from one VM to another.

There is one ServletContext per VM. There is one ServletConfig per servlet, per VM. But there is only one HttpSession object for a given session ID per web app, regardless of how many VM’s the app is distributed across.

How an app server vendor handles clustering and web app distribution varies with each vendor, and there’s no guarantee in the J2EE spec that a vendor has to support distributed apps. But the picture here gives you a high-level idea of how it works. The key point is that while other parts of the app are replicated on each node/VM, the session objects are moved. And that is guaranteed. In other words, if the vendor does support distributed apps, then the Container is required to migrate sessions across VMs. And that includes migrating session attributes as well.