Difference between Stateless and Stateful session bean

Question

I knew stateful beans maintain conversational session between different instance method call,but stateless will not.My question,assume I have a stateless bean implementation like below

import javax.ejb.Stateful;
import javax.ejb.Stateless;

import com.tata.ejb3.data.HelloEJBInterface;

@Stateless
public class ValueEJB implements ValueEJBInterface{

    private int value;
    @Override
    public int getValue() {
        return this.value;
    }

    @Override
    public void setValue(int value) {
        this.value = value;
    }
}

I have my bean client(A servlet) which initiates bean invocation as below

@EJB(mappedName="E/ValueEJB /remote")
ValueEJBInterface value;

....

value.setValue(250);
System.out.println(value.getValue());//This statement prints the value 250

....

According to my understanding as my bean is stateless bean it should not displayed with value 250.

private int value; is an instant variable,if one stateless method set its value , the value will be expired on method exit.But here, I am able to get the value '250' even via my second method call. Is it a violation of stateless concept? Am I lacking something?

Damaris

Answer 1

Difference between Stateful v Stateless bean behavior when calling different methods.

---

STATEFUL: When calling different methods on a Stateful Bean, different bean instances are created.

((MyStatefulBeanRemote) ctx.lookup("ejb/MyStatefulBean")).doingStatefulThing();

((MyStatefulBeanRemote) ctx.lookup("ejb/MyStatefulBean")).doingNothingStatefulThing();

***Output: Note the creation of separate objects.***

INFO: Calling doingStatefulThing...com.myeclipseide.ejb3.stateful.**MyStatefulBean@2fe395**

INFO: Calling doingNothingStatefulThing...com.myeclipseide.ejb3.stateful.**MyStatefulBean@81cfcb**

---

STATELESS: When calling different methods on a Stateless Bean, the beans are pooled, hence no new instances of the bean are created.

((MyStatelessBeanRemote) ctx.lookup("ejb/MyStatelessBean")).doSomething(); 

((MyStatelessBeanRemote) ctx.lookup("ejb/MyStatelessBean")).doNothing();

***Output: Note the reuse of he bean object.***

INFO: Doing something ...com.myeclipseide.ejb3.stateless.**MyBean@213b61**

INFO: Doing Nothing ...com.myeclipseide.ejb3.stateless.**MyBean@213b61**

Homeo

Answer 2

Interesting question and basically you are totally right. I did some research and the general advice is to: "Expect your bean to forget everything after each method call ..." (page 81). Furthermore, according to that resource, the algorithm responsible for maintaining the state of Stateless Session Beans is container / vendor specific. So the container may choose to destroy, recreate or clear the instance after method execution.

You could create a multi threaded test and see how it behaves with multpile clients.

Canonize

Okay.You are right.If I am not wrong,the similar scenario behaved differently in EJB2.0/Weblogic ejb container,where my EJB client got 0 as getValue, means on my next call, container served with a different ejb instance. – Damaris

Answer 3

There is no violation of any concept. Its because the same instance of bean is picked by the container from the pool to serve other request.

Stateless beans are pooled & therefore they have performance benefit over statefull beans, also their main purpose is processing without holding any state.

Sensitive or user specific data shouldn't be stored in instance variables of stateless beans. They should be used extensively to process data without any consideration of state.

Can refer here for their life-cycle events handled by the container.

Zonate

Thanks for the details.One more question here. @stateless(mappedName="XXX"), would my ejb be referred via XXX here after? I have seen JBoss AS given a differnt JNDI mapping despite of XXX.Is it purely vendor specific? – Damaris

No, mappedName is optional attribute & is left to the vendor, JBoss opts out this attribute & uses its own convention. – Zonate

I have noticed one more interesting thing, mappedName is taken only when my service interface was Remote interface.When I specified mappedName for an EJB whose service interface annotated with @Local (or not even specified anything here), my JBoss container ignored it and bound with its own JNDI, somthing like xxxxx/Local – Damaris

You can use JBoss specific annotation @LocalBinding or @RemoteBinding – Zonate