Java Reference
In-Depth Information
more urgent tasks (probably beans that are being actively called) to use resources
tied up by otherwise idle beans. Think of this as like memory swap in an
operating system. The bean will save any data and context information into
some sort of persistent storage, which may be a database, flat files, XML files,
whatever, when it is passivated.
Context switching.
Since both session and entity beans may be called
upon to service requests from multiple clients, it is necessary to provide a
method whereby the container can notify the bean which “context” (which
may be loosely said to be a client) is active at the moment. In stateless session
beans this is not necessarily implemented, but in stateful session beans and in
entity beans this activity must be supported.
How is this distinct from passivation and activation? Passivation is the
temporary “swapping out” of a bean to make room for something else. Context
switching is the move of a
Bean
instance from client to client. Or, to put it
another way, passivation makes room for some other bean to become active
and serve a client.
1
Context switching switches a given bean from client
to client.
2
21.2.1.2
A J2EE application server has two
containers
: a Web container and an EJB
container. You can also think of these as “servers” in the more classic sense.
J2EE calls them containers because it emphasizes the idea that you place Java
objects (applets, servlets, and Enterprise JavaBeans) into the container that can
run them (a browser, a Web container, an EJB container). The J2EE specifica-
tion specifies the exact relationship between these application objects and their
container. For EJB's, the container provides lifecycle control, network manage-
ment, load management, perhaps clustering services, CMP (container-managed
persistence) services, and so on. We'll talk a lot more about container services
The EJB Container
1. This is a simplification. A container can passivate a bean to make resources available for any
purpose, not just for another EJB. Beans might be passivated because some process on the
server outside the application server needs resources. It is entirely dependent on how the
application server is written. What is said here is conceptually true, if not actually true ;-)
2. Again, saying “client-to-client” is a simplification. A single client may have multiple threads
interacting with multiple beans, and a context switch might be performed to serve different
requests from a single client. Again: conceptually true, if not actually true.
