Identify correct and incorrect statements or examples that compare the purpose and use of Stateful and Stateless Session Beans SCBCD

Identify correct and incorrect statements or examples that compare the purpose and use of Stateful and Stateless Session Beans

Once again, the EJB 3.0 Core Contracts document does a pretty good job at describing exactly what a Session bean is:

Session Objects

A typical session object has the following characteristics:
• Executes on behalf of a single client.
• Can be transaction-aware.
• Updates shared data in an underlying database.
• Does not represent directly shared data in the database, although it may access and update such data.
• Is relatively short-lived.
• Is removed when the EJB container crashes. The client has to re-establish a new session objectto continue computation.

A typical EJB container provides a scalable runtime environment to execute a large number of session objects concurrently.
The EJB specification defines both stateful and stateless session beans. There are differences in the API between stateful session beans and stateless session beans.




Page 83 of the EJB Core Contract document goes into more detail on Stateless Session Beans in EJB3.0:



Stateless Session Beans

Stateless session beans are session beans whose instances have no conversational state. This means that all bean instances are equivalent when they are not involved in servicing a client invoked method. The term stateless signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such state include an open database connection and an object reference to an enterprise bean object.
The Bean Provider must exercise caution if retaining any application state across method calls. In particular, references to common bean state should not be returned through multiple local interface method calls.
Because all instances of a stateless session bean are equivalent, the container can choose to delegate a client-invoked method to any available instance. This means, for example, that the container may delegate the requests from the same client within the same transaction to different instances, and that the container may interleave requests from multiple transactions to the same instance.
A container only needs to retain the number of instances required to service the current client load. Due to client think time, this number is typically much smaller than the number of active clients. Passivaion is not needed or used for stateless sessions. The container creates another stateless session bean instance if one is needed to handle an increase in client work load. If a stateless session bean is not needed to handle the current client work load, the container can destroy it. Because stateless session beans minimize the resources needed to support a large population of clients, depending on the implementation of the container, applications that use stateless session beans may scale somewhat better than those using stateful session beans. However, this benefit may be offset by the increased complexity of the client application that uses the stateless beans.

Compatibility Note: Local and remote clients using the EJB 2.1 client view interfaces use the create and remove methods on the home interface of a stateless session bean in the same way as on a stateful session bean. To the EJB 2.1 client, it appears as if the client controls the life cycle of the session object.
However, the container handles the create and remove calls without necessarily creating and removing an EJB instance. The home interface of a stateless session bean must have one create method that takes no arguments. The create method of the remote home interface must return the session bean’s remote interface. The create method of the local home interface must return the session bean’s local interface. There can be no other create methods in the home interface. There is no fixed mapping between clients and stateless instances. The container simply delegates a client’s work to any available instance that is method-ready. A stateless session bean must not implement the javax.ejb.SessionSynchronization interace.

There's also a little bit of good information on Stateful Session Bean EJBs:

• stateful—the session bean instances contain conversational state which must be retained across methods and transactions