The three basic session beans: stateless, stateful, and singleton, are at the heart of most EJB applications. They each differ in their purpose and capabilities. This chapter provides numerous examples of how they can be used and provides insight into how they work.

Many of the examples in this chapter are based on servlets. The use of servlets, specifically the doGet and doPost methods are detailed in Chapter 1, Getting Started With EJBs. When you create your projects, be sure to enable context and dependency injection. The code examples do not include import statements.

Also note that in IDEs such as NetBeans, wizards are frequently used to add elements such as servlets to an application. During this process they will automatically modify the web.xml file to map a servlet's name to an URL pattern. If you choose not to use a wizard, you will need to explicitly modify the file itself. Deployment descriptor files are discussed in more detail in Chapter 11,

Let's start our discussion with the stateless EJB. This type of session bean has no conversational state. Whenever a client invokes a method of a stateless EJB, it is as if this or any other method of the EJB has never been executed. For example, a method may be passed a height and width to compute the area of a surface and return a result. Any previous height or width values stored with the bean are to be ignored.

Since no state information is maintained, all stateless EJBs of this type are considered to be equivalent by the EJB container. The server's EJB container allocates stateless EJBs and typically reuses them within and between clients. No permanent reference between a client and a stateless EJB is maintained.

A stateful session bean, in contrast, will maintain its state between subsequent client calls. The client uses setter type methods to affect the state of the EJB. Subsequent method calls can use these values to compute and return a value to the client. As such, a stateful bean is not shared between clients. In addition, it can be passivated, that is, temporarily stored between invocations by the server should the server need to remove the bean from memory. Later the bean and its state can be restored as if nothing has happened. A bean may be passivated for a number of reasons. For example, the EJB container may fail yet the server may stay up. When the container is restored the bean can be activated.

A singleton bean is similar to a stateful bean in that state information is maintained between method invocations. However, there is only one singleton bean for the application and it is shared by all of the EJBs and clients of an application. This type of bean provides a convenient means of maintaining the overall state of an application.

The first three recipes illustrate how to create stateless, stateful, and singleton session beans. They further expound upon the behavior of these types of beans.

There is only one instance of a singleton available to an application at a time. However, it is possible to have multiple different singletons in an application. When distributed over multiple Java Virtual Machine (JVM)s, there is only one singleton per JVM.

By default, singletons are not created until a method of the bean is invoked. However, the creation of the singleton can be forced using the @Startup annotation. This creation technique is referred to as eager initialization. The effect of most annotations can also be affected using deployment descriptors. The use of deployment descriptors is covered in Chapter 11,

There are occasions when it can be advantageous to use multiple singleton beans in the same application. Each singleton can be used to manage a particular aspect of the application. In some applications where multiple singletons are used, the order in which the singletons are created and initialized can be an issue. The @DependsOn annotation provides a way of explicitly controlling the order of singleton initialization. The recipe, Using multiple singleton beans, addresses this topic.

EJBs can be accessed either locally or remotely. Local access uses a no-interface view or implements a local interface declaration. A no-interface view exposes all of the public methods of an EJB whereas the local and remote interfaces usually expose only a subset of the public methods. Remote EJBs implement a remote interface. The difference between these interfaces involves which methods are made visible and how information is passed between the EJB and a client.

The use of a local interface does not involve a remote procedure call but does require the client to be part of the same JVM process. In addition, parameters are passed by reference. An EJB accessed remotely will use a remote procedure call and parameters are passed by value. That is, only a copy of the object is passed and any modification of the object will not be reflected in the original object. This may be a problem if, for example, the client needs to modify the original object.

The Using session beans with more than one business interface and Understanding parameter behavior and granularity recipes, address these issues in more detail.

Concurrency is concerned with multiple access of a method by more than one client at a time. If this concurrent access is not planned carefully, data can be corrupted and unpredictable results can occur.

There are two types of locks that can be assigned to an EJB and/or its methods: a read lock and a write lock. When a lock is applied to a class, all of the methods of the class use that locking mechanism. This lock can be overridden by specifying the locking type for an individual method.

A read lock indicates concurrent access to the method is permitted. It is assumed that multiple read operations will not be a problem and will not corrupt the state of the EJB.

A write lock does not permit concurrent access to the method. Once a client begins executing a method marked with a write lock, no other clients are permitted access to the method until the method invocation completes. Other clients are blocked. This is the default concurrent behavior of singletons.

There is nothing the programmer needs to do to enforce concurrent access. However, if more control on the type of concurrent access used is needed, then the programmer can change the type of lock on a method by method basis or use bean-managed concurrency.

The Using container managed concurrency and Using bean managed concurrency recipes address the concurrency issues.

Sometimes it is desirable to invoke a method of an EJB and not wait for the method to complete its execution. Either the client may not necessarily be concerned with whether the method executes successfully or the client may want to check on its success or failure later. Asynchronous methods provide this capability and the Using an asynchronous method to create a background process recipe illustrates this approach.

While it is not obvious from this discussion, EJB 3.1 introduced several new features. For example, there is no need to define explicit interfaces for beans as required in the previous version. Another significant addition is the singleton bean. Prior to EJB 3.1, it was more difficult to implement the singleton design pattern. The ability to invoke session beans asynchronously was also added in this version.