Head First EJB

Chapter 4. Session Bean Lifecycle: Being a Session Bean

Session beans are created and removed. If you’re lucky, you’re a stateless bean. Because the life of a stateful bean is tied to the whims of a heartless client. Stateful beans are created at the client’s insistence, and exist only to serve that one client. As a stateful bean, the best you can hope for is that the client crashes or forgets to call remove(); it might take the Container a while to figure out you’ve become useless. But ahhhh, the life of a stateless bean is fabulous! Pools, those little umbrella drinks, and no boredom since you get to meet so many different clients. Of course, even a stateless bean dies with an unchecked exception...

Objectives

Session Beans

Official:		What it really means:
3.1	Identify correct and incorrect statements or examples about session beans, including conversational state, the SessionBean interface, and create methods.	This objective can hit you on anything related to session beans, so you pretty much have to know it all, including the details of both stateless and stateful bean lifecycles, the container callback methods of SessionBean, what you must write in a bean class, and what a bean can get from its EJBContext. Anything covered by the other session bean objectives is fair game.
3.2	Identify the use of, and the behavior of, the ejbPassivate method in a session bean, including the responsibilities of both the container and the bean provider.	First, you have to know that passivation is for only stateful session beans. Stateless beans go back to the bean pool without going through passivation. So, ejbPassivate() will never be called on a stateless bean. You have to know that your responsibility in ejbPassivate() is to make sure that when the method ends, your bean is ready for passivation, and that passivation may or may not involve serialization. You must know the state that your instance variables must be in at the time ejbPassivate() ends. And even though this objective doesn’t mention ejbActivate(), you have to understand how ejbActivate() works as well.
3.3	Identify the interface and method for each of the following: retrieve the session bean’s remote home interface, retrieve the session bean’s local component interface, determine if the session bean’s caller has a particular role, allow the instance to mark the current transaction as a rollback, retrieve the UserTransaction interface, prepare the instance for reuse following passivation, release resources prior to removal, identify the invoker of the bean instance’s component interface, be notified that a new transaction has begun, be notified that the current transaction has completed.	You must be able to look at a description of a desired behavior, like, figure out the security principal of the client, and know which method you can call, and on which interface, to get that behavior (in this case, getCallerPrincipal() called on the SessionContext interface). To answer these questions, you have to know every method in the three key interfaces: SessionBean (the interface your bean implements), SessionContext (the interface your bean has a reference to), and SessionSynchronization (an optional interface that a stateful bean can implement). In this chapter, we’ll cover everything about session bean interfaces except SessionSynchronization, which is covered in the transactions chapter.
3.4	Match correct descriptions about purpose and function with which session bean type they apply to: stateless, stateful, or both.	You have to know the differences between stateless and stateful beans including when you’d choose one over the other. You must know the bean rules including: there can be only one create method in a stateless bean, and it must have no arguments; only stateful beans can implement SessionSynchronization, both stateless and stateful beans will not survive a container crash, stateless beans will never be passivated, stateless bean creation and removal is not tied to the client.
3.5	Given a list of responsibilities related to session beans, indentify those which are the responsibility of the session bean provider, and those which are the responsibility of the EJB container provider.	You have to know what is and isn’t guaranteed in the spec. For example, the container won’t allow concurrent access to a single session bean (if client A is using the bean, client B will get an exception if it calls a method on that bean). And the container isn’t required to allow a bean in one EAR file to be a local client to a bean in a different EAR. And you have to know exactly which classes and methods are implemented by you (the bean, the ejbRemove() and ejbCreate() methods, etc.), and which are implemented by the container (the handles, the home and component objects, the stubs (for Remote client interfaces), the getEJBObject() method, etc.). Most of what’s in this objective overlaps with 3.1, 3.2, and 3.6.
3.6	Given a list of requirements, identify those which are the requirements for a session bean class, remote component interface, remote home interface, create methods, business methods, local component interface, remote component interface.	This is about knowing bean law—the rules you have to follow, according to the spec, even in the cases where compiler won’t care if you don’t. For example, you must have a matching ejbCreate() method for each create method in the home, but the compiler won’t stop you if you leave it out. And you must know that local interface methods must not declare a RemoteException, but Remote interface methods must. And you must know that object type arguments to a Remote interface method are sent as serialized copies of the object, while arguments to local interfaces are sent as copies of the reference.