replicated—including replicating all the session state data on every call, so that an applica-
tion that did not call the setAttribute() method would still function correctly. That works
functionally, but the performance will be much worse than if the app server could replicate
only the changed attributes.
The moral of the story: call the setAttribute() method whenever you change the value of
an object stored in the session state, and make sure that your application server is configured
to replicate only changed data.
1. Session state can have a major impact on the performance of an application serv-
2. To reduce the effect of session state on the garbage collector, keep as little data in
the session state as possible, and expire the session as soon as possible.
3. Look into app server-specific tunings to move stale session data out of the heap.
4. When using high availability, make sure to configure the application server to rep-
licate only attributes that have changed.
pools; everything that chapter says about properly sizing the thread pool applies to applica-
Application servers typically have more than one thread pool. One thread pool is commonly
used to handle servlet requests, another handles remote EJB requests, and a third might
handle Java Message Service (JMS) requests. Some application servers also allow multiple
pools to be used for each kind of traffic: for example, servlet requests to different URLs or
calls to different remote EJBs can be handled by separate thread pools.
Separate thread pools allow limited prioritization of different traffic within the application
server. Take the case of an application server that is running on a machine with four CPUs;
assume that its HTTP thread pool has 12 threads and its EJB thread pool has 4. All threads
will compete for the CPU, but when all threads are busy, a servlet request will be three times