Java Reference
In-Depth Information
This approach greatly simplifies the programming for session state manage-
ment. This is because the architecture completely insulates the programmer
from distribution issues.
Despite the fact that this technique has been widely and successfully
deployed, it does have its limitations. Proxy architectures can sometimes lead
to sporadic behavior. If a user's Internet service or company can route
through several different proxies, the dispatcher may route contiguous
requests to different servers, leading to unpredictable results for the user.
(Some dispatcher technologies do not have this problem.) Also, because there
is no replication of the session data, session data can be lost if the user's first
application server crashes.
10.5.2
Solution 2: Using a distributed state management service
Most web application server vendors have distributed state management ser-
vices. The services provide a dictionary (a session
ID
associated with data) for
state management. A framework either replicates this data or makes this data
available through distributed requests.
This solution also frees the programmer from having to deal with the dis-
tributed architecture. The performance of distributed state management ser-
vices will probably improve over time as vendors iterate on them. These
vendors also use approaches that are easily adapted to open standards. Some of
these solutions add failure safety by replicating the state to another site.
Keep in mind that distributed replication and communication comes with
overhead. This performance penalty can be severe compared with localized
session state management. Also, performance suffers for very large blocks of
session data.
10.5.3
Using custom session bean solutions
Another approach is to use a session bean to communicate with a persistent
store, state table, or database elsewhere. Session beans can be relatively light-
weight alternatives to entity
EJB
s. With this solution, we can support much
larger session blocks than by using the native alternatives. Since the session
bean is custom, it is very flexible.
Using a custom session bean does have disadvantages:
Stateful session beans can be difficult to clean up.
Memory leaks are common with this type of architecture.
Data in stateful session beans is not transactional or fail-safe.
