Java™ Application Development on Linux - Dator

476Chapter 21Introduction to Enterprise JavaBeansmore urgent tasks (probably beans that are being actively called) to use resourcestied up by otherwise idle beans. Think of this as like memory swap in anoperating system. The bean will save any data and context information intosome 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 calledupon to service requests from multiple clients, it is necessary to provide amethod whereby the container can notify the bean which “context” (whichmay be loosely said to be a client) is active at the moment. In stateless sessionbeans this is not necessarily implemented, but in stateful session beans and inentity beans this activity must be supported.How is this distinct from passivation and activation? Passivation is thetemporary “swapping out” of a bean to make room for something else. Contextswitching is the move of a Bean instance from client to client. Or, to put itanother way, passivation makes room for some other bean to become activeand serve a client. 1 Context switching switches a given bean from clientto client. 221.2.1.2 The EJB ContainerA J2EE application server has two containers: a Web container and an EJBcontainer. 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 Javaobjects (applets, servlets, and Enterprise JavaBeans) into the container that canrun them (a browser, a Web container, an EJB container). The J2EE specificationspecifies the exact relationship between these application objects and theircontainer. For EJB’s, the container provides lifecycle control, network management,load management, perhaps clustering services, CMP (container-managedpersistence) services, and so on. We’ll talk a lot more about container services1. This is a simplification. A container can passivate a bean to make resources available for anypurpose, not just for another EJB. Beans might be passivated because some process on theserver outside the application server needs resources. It is entirely dependent on how theapplication 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 threadsinteracting with multiple beans, and a context switch might be performed to serve differentrequests from a single client. Again: conceptually true, if not actually true.