Session beans can either be stateful or stateless. With stateful beans, the EJB container saves internal bean data during and in between method calls on the client’s behalf. With stateless beans, the clients may call any available instance of an instantiated bean for as long as the EJB container has the ability to pool stateless beans. This enables the number of instantiations of a bean to be reduced, thereby reducing required resources.
Stateless Session Beans
A session bean represents work performed by a single client. That work can be performed within a single method invocation, or it may span multiple method invocations. If the work does span more than one method, the object must retain the user’s object state across the method calls, and a stateful session bean would therefore be required.
Generally, stateless beans are intended to perform individual operations automatically and don’t maintain state across method invocations. They’re also amorphous, in that any client can use any instance of a stateless bean at any time at the container’s discretion. They are the lightest weight and easiest to manage of the various EJB component configurations.
Stateful Session Beans
Stateful session beans maintain state both within and between transactions. Each stateful session bean is therefore associated with a specific client. Containers are able to save and retrieve a bean’s state automatically while managing instance pools (as opposed to bean pools) of stateful session beans.
Stateful session beans maintain data consistency by updating their fields each time a transaction is committed. To keep informed of changes in transaction status, a stateful session bean implements the SessionSynchronization interface. The container calls methods of this interface while it initiates and completes transactions involving the bean.
Session beans, whether stateful or stateless, are not designed to be persistent. The data maintained by stateful session beans is intended to be transitional. It is used solely for a particular session with a particular client. A stateful session bean instance typically can’t survive system failures and other destructive events. While a session bean has a container-provided identity (called its handle), that identity passes when the client removes the session bean at the end of a session. If a client needs to revive a stateful session bean that has disappeared, it must provide its own means to reconstruct the bean’s state.
Stateful vs. Stateless Session Beans
A stateful session bean will maintain a conversational state with a client. The state of the session is maintained for the duration of the conversation between the client and the stateful session bean. When the client removes the stateful session bean, its session ends and the state is destroyed. The transient nature of the state of the stateful session bean should not be problematic for either the client or the bean, because once the conversation between the client and the stateful session bean ends, neither the client nor the stateful session bean should have any use for the state.
A stateless session bean will not maintain conversational states for specific clients longer than the period of an individual method invocation. Instance variables used by a method of a stateless bean may have a state, but only for the duration of the method invocation. After a method has finished running either successfully or unsuccessfully, the states of all its instance variables are dropped. The transient nature of this state gives the stateless session bean beneficial attributes, such as the following:
1. Bean pooling Any stateless session bean method instance that is not currently invoked is equally available to be called by an EJB container or application server to service the request of a client. This allows the EJB container to pool stateless bean instances and increase performance.
2. Scalability Because stateless session beans are able to service multiple clients, they tend to be more scalable when applications have a large number of clients. When compared to stateful session beans, stateless session beans usually require less instantiation.
3. Performance An EJB container will never move a stateless session bean from RAM out to a secondary storage, which it may do with a stateful session bean; therefore, stateless session beans may offer greater performance than stateful session beans.
Since no explicit mapping exists between multiple clients and stateless bean instances, the EJB container is free to service any client’s request with any available instance. Even though the client calls the create() and remove() methods of the stateless session bean, making it appear that the client is controlling the lifecycle of an EJB, it is actually the EJB container that is handling the create() and remove() methods without necessarily instantiating or destroying an EJB instance.
When to use session beans:
Generally session beans are used in the following circumstances:
Generally session beans are used in the following circumstances:
- When there is only one client is accessing the beans instance at a given time.
- When the bean is not persistent that means the bean is going to exist no longer.
- The bean is implementing the web services.
Stateful session beans are useful in the following circumstances:
- What the bean wants to holds information about the client across method invocation.
- When the bean works as the mediator between the client and the other component of the application.
- When the bean have to manage the work flow of several other enterprise beans.
Stateless session beans are appropriate in the circumstances illustrated below:
- If the bean does not contain the data for a specific client.
- If there is only one method invocation among all the clients to perform the generic task.
EJB3 Creation
1. EJB3 can be created in Eclipse as below
EJB Look Up
1. Local EJB's can be used with in the same JVM, not allowed to look up(use) using the standalone application.
2. For look up and use the any EJB need to have Remote interface.
Look up of Remote EJB in Jboss Server
Properties props = new Properties();
props.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
props.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
props.setProperty("java.naming.provider.url", "127.0.0.1:1099");
Context ctx = new InitialContext(props);
EmployeeEJBRemote bean = (EmployeeEJBRemote) ctx.lookup("EmployeeEJB");
In case of non interface EJB, not allowed to type cast of proxy, have to use proxy directly.
Look up of Remote EJB in Jboss Server
Properties props = new Properties();
props.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
props.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
props.setProperty("java.naming.provider.url", "127.0.0.1:1099");
Context ctx = new InitialContext(props);
EmployeeEJBRemote bean = (EmployeeEJBRemote) ctx.lookup("EmployeeEJB");
In case of non interface EJB, not allowed to type cast of proxy, have to use proxy directly.
EJB Injection
EJBs can be injected in to another EJB's or Servlet's/JSP's
// No interface EJB
@EJB(name="SampleEJB")
SampleEJB sampleEJB;
// Remote interface EJB
@EJB(mappedName="TestEJB")
TestEJBRemote testEJB;
// both interface EJB
@EJB(mappedName="EmployeeEJB")
EmployeeEJBRemote employeeEJB ;
// local interface EJB
@EJB(name="sample.ejb.POCEJBLocal")
POCEJBLocal pocejbLocal;
@EJB(name="SampleEJB")
SampleEJB sampleEJB;
// Remote interface EJB
@EJB(mappedName="TestEJB")
TestEJBRemote testEJB;
// both interface EJB
@EJB(mappedName="EmployeeEJB")
EmployeeEJBRemote employeeEJB ;
// local interface EJB
@EJB(name="sample.ejb.POCEJBLocal")
POCEJBLocal pocejbLocal;
