Building business logic with session beans - EJB 3 in Action - page 91

Figure 3.6. A bean instance is reserved for each client for the duration of the bean. The bean is thus able to store
client state information until the bean is removed by the client or times out.
In addition to ensuring that the same bean is used for all invocations from a given client, the
container also ensures that only one thread is accessing the bean at a time. This means that
you don't have to worry about enforcing synchronization yourself—multiple threads can
access the bean and the container will ensure that the bean isn't in an inconsistent state. But
by giving up some control, you also lose some flexibility—only one thread at a time—no
exceptions.
The one-to-one mapping between a client and a bean instance makes saving a bean conver-
sational state in a useful manner possible. But this one-to-one correlation comes at a price.
Bean instances can't be readily returned to a pool and reused for another client. Instead, a
bean instance must be squirreled away in memory to wait for the next request from the cli-
ent owning the session. As a result, stateful session bean instances held by a large number
of concurrent clients can have a significant memory footprint. An optimization technique
called passivation , which we'll discuss in section 3.3.2 , is used to alleviate this problem.