Java Reference
In-Depth Information
rule of thumb is something under 2K-4K. This isn't a hard
rule. 8K is still okay, but obviously slower than 2K.
One common problem is in using HttpSession to cache
information that can be easily recreated, if necessary. Since
the sessions are persisted, this is a very expensive decision
forcing unnecessary serialization and writing of the data.
Instead, use an in memory hash table to cache the data and
just keep a key to the data in the session. This enables the data
to be recreated should the user fail over to another application
server.
Enable session persistence, if you don't enable session
persistence, should a server is stopped for any reason (a
server failure or ordinary maintenance); any user that is
currently on that application server will lose their session.
That makes for a very unpleasant experience. They have to
log in again and redo whatever they were working on. If
instead, session persistence is enabled, AS will automatically
move the user (and their session) to another application
server, transparently. They won't even know it happened. This
works so well, that we've actually seen production systems
that crashes regularly still provide adequate service.
Business Tier
Always
use
session
facades
whenever
you
use
EJB
components
Use local EJBs when architecturally appropriate.
Using a session facade is one of the best-established best
practices for the use of EJBs. In fact, the general practice is
