Stateful Session Bean lifecycle

 

The stateful session bean is a session bean that maintains its internal states. If the client invokes method calls against the same bean stub, the calls are always tunneled to the same bean instance in the container. So, all field variables in the bean instance retain their values as long as the client application retains the bean stub (or reference for a local client).  

The stateful session bean is typically used to track states in an application: In a web application, the servlet (or JSP page) caches the bean stub as an attribute in the HttpSession object. The HTTP session's state is therefore tracked and stored in the bean instance.

In a rich client Java application (e.g., Swing application), the application determines what is a "session" and caches the stateful session bean stub accordingly.

 It is very easy to create a Stateful Bean with EJB 3.0. All bean types are homeless in EJB 3.0 so all you have to do to create a Stateful bean is to create a bean class and have it implement at least one interface. Take a look at this:

@Stateful

public class HelloWorldBean implements HelloWorldItf, Serializable {

    int counter;

    public void doSomething() {
        counter++;
        System.out.println("Value of counter is " + counter);

    }


    @PostConstruct
    public void initialize () {
        // As with stateless EJB, the container immediately calls the 
        // annotated method after a bean instance 
        // is instantiated. 
    }

    @PreDestroy
    public void exit () {
        // The annotated method is called before the container destroys 
        // an unused or expired bean instance from its object pool.
    }

    @PrePassivate
    public void beforePassivate () {
        // Called before SFSB is passivated 
    }


    @PostActivate
    public void afterActivation () {
        // Called before after SFSB is restored 
    }

    @Init
    public void initialize () {
        // Called to initialize SFSB 
    }

    @Remove
    public void stopSession () {
        // Call to this method signals the container
        // to remove this bean instance and terminates
        // the session. The method body can be empty.
    } 

}

The first thing to notice is that the class is tagged as @Stateful. This marks the class as a stateful bean and the deployer will deploy that class as a stateful bean EJB container.

 So a Stateful SB can be basically in three States: Does not Exist, Ready and Passivated. When the Bean is first instantiated it is moved to the Ready State. If the instance is idle for too long, the container might passivate it and store its state to a cache. The method is tagged by the annotation @PrePassivate.

 

lifesfsb

Picture 2: Stateful Session Bean lifecycle

When the client uses the passivated stateful session bean again, a new instance is created and the bean state is restored. The method tagged by this annotation is @PostActivate and when it's called the activated bean instance is ready.

Another useful annotation for a lifecycle method, especially for stateful session beans, is @Remove. This is not a callback method: when the application calls remove on the bean instance it will signal the container to remove this bean instance and terminates the session. 

How do you control the timeout period ?

Stateful session beans have configurable timeout values which can control the amount of time a bean can remain idle prior to passivation or removal. Notice the @org.jboss.annotation.ejb.cache.simple.CacheConfig annotation. The idleTimeoutSeconds parameter configures the amount of idle time before the bean is passivated and the removalTimeoutSeconds configures the amount of idle time before the bean is permanently removed. For example, in order to set the timeout to 300 seconds:

@CacheConfig (idleTimeoutSeconds=300)

Client lookup 

public class Client {

 public static void main(String[] args) throws Exception {
  Properties p = new Properties(); 
  p.put(Context.INITIAL_CONTEXT_FACTORY, 
     "org.jnp.interfaces.NamingContextFactory"); 
  p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces"); 
  p.put(Context.PROVIDER_URL, "10.2.25.35:1100");

  InitialContext ctx = new InitialContext(p);
  HelloBeanItf ejb = (HelloBeanItf) ctx.lookup("cluster/HelloBean/remote");

  ejb.doSomething();

 }
}

The session bean client obtains a stub object of the bean via JNDI (Java Naming and Directory Interface). Provided by the container, the stub object implements the session bean's business interface. All calls made to the stub object are routed to the container and invoked against the managed bean instances.

For stateless session beans, you can obtain a new stub every time you make a call. For stateful session beans, you must cache the stub on the client side so the container knows to provide you with the same bean instance for each subsequent call

0
0
0
s2smodern

Related articles available on mastertheboss.com

JBoss MDB 3.0

Message-driven beans (MDBs) are stateless, server-side, transacti

JBoss EJB 3 BMT

In a Bean Managed Transaction, the code in the EJB or Message Dri

How do you keep your EJB callbacks separated from biz. methods?

JBoss daily recipe

How to set EJB timeout period ?

JBoss recipe of the day

How to add a Selector with MDB 3.0 ?

Message selectors allow an MDB to be more selective about the mes

How to create a MDB 3.0 singleton ?

  EJB3 uses the resource adapter.  When using the resource adapt