• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

understanding of stateless session beans

 
Bartender
Posts: 1104
10
Netbeans IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
I have some doubts in understanding stateless session beans. I wrote a stateless session bean having an instance variable i(int). I have 2 business methods in which I increase the value of i and print. Now, when I call both the methods from the client, I expected both methods to print "1" as state is not maintained between client calls. But, to my surprise it printed "1" and "2", which means the state was sort of maintained.

I again ran the client, and this time it printed "3" and "4"! This was because I got the same bean again and it was holding the old values still.
(I am deploying on JBoss).

So, if I rightly understand, a stateless session can't maintain state in the "right" way, rather than saying it dosen't maintian state.

Please clarify whether my understanding is correct.

Thank You,
Ranga.
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As I understand (please someone else, confirm it)...

your bean doesn't maintain the state. Why ? The EJB Container could remove any time, the SLSB (StateLess Session Bean) of the memory.

The doc says that is doesn't maintain the state to make sure that you don't rely on it.

You typically called 4 times in a row, on a SLSB that wasn't destroyed. In other word, your calls were pretty close together to not see that SLSB been killed between calls. Try with some time between, you might get the behaviour that you are looking for.

Also (and more importantly), remember that maintaining the state if for ONLY ONE SPECIFIC client ! The fact that the value of I is kept doesn't really matter. The value would be changed by ANY CLIENT, not a SPECIFIC one. So, again, not useful here.

hope this helps !
 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
THe SLSB does not maintain CLIENT SPECIFIC state. It can have it's own instance variables and state(not client related) which can be used while processing client's requests. Client should never rely on state of the bean.

Everytime a client sends a request, the container picks a bean from the pool, process clients request and return the bean to the pool.
In your case, probably the same bean was picked for multiple calls from the client(ur container might have had only one bean in the pool-just a possiblity).
 
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


We cannnot probably ask the client to 'wait' for sometime and then 'see the magic'!

Also, the same bean (instance) servicing again should not ulter the behaviour of a statelessSessionBean.

I too am waiting for a proper reason if anyone knows.

Regards,
Leena
 
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ranaganathan,
Can you to post your client code here?
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As Shreyas said, a SLSB does not maintain CLIENT STATE, but it can have its own state.

If the same bean instance has different behaviour for multiple calls then it is a design flaw in the bean.

One thing I use quite often are environment variables. I do a jndi lookup of jave:comp/env/xxxx during ejbCreate and save the value in an instance variable. It then becomes "state", but it is not state that is specific to any one client. If the container reset the instance variables between calls, I would have to do that lookup at the beginning of each call. That can become expensive.

If you choose to have an int as an instance variable, then it is also "state" that is not specific to a client. It is up to you to make sure it is properly initialized in ejbCreate, or during each call.
 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What ???

It's may be a flaw in a vendor especific way , we would'nt rely that ! The especification is the master and we must obey the rules to our code if we supposed that it's supported in a EJB 2.0 containers.

In your case, the fault takes place because the same instance of stateless bean was invoked to work in other multiples client calls without go back to the pool.

Hope this help.

Regards.

Paulo Nunes
 
Brian Tinnel
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What I meant by a flaw was doing something that assumed that the instance variables would be reset between calls to business methods. I'm not sure why you think the bean wasn't put back in the pool.

From section 7.8 of the EJB 2.0 spec:

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 states include an open database connection and an object reference to an EJB object.

 
Ranganathan Kaliyur Mannar
Bartender
Posts: 1104
10
Netbeans IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Shreyas Reddy's explanation. The stateless SB has it's own state, but not a client specific one.

Thanks to all for your comments,
Ranga.
 
Paulo Asterio Nunes
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Guys,

Sorry all, I was wrong , Stateless session beans could have instance variables to hold values among client calls and these variables do not needed to be cleared anyway. Therefore the state of the bean is not CLIENT SPECIFIC like Shreyas sad.

Sorry again !!!

Best Regards,

Paulo Nunes
Brazil
MCP OCP IBM285 SCJP 1.4 SCWCD 1.4 SCBCD 1.3
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi!
I am sorry if i confuse you further... but this is what i understood ... any body feels my understanding is wrong please correct me.....(even i am on the verge of preparing fot the SCBCD)
I was also having the same question in mind when i was trying to practically implement to see the difference between the stateless and stateful. What i understood after studying the HF EJB and going back to the code is .....

1. It is true that the Stateless session beans will not save the conversational state between the two method calls. Which does not and need not directly imply that you cannot have member variables if the bean is stateless. you can have the member variables which because of the nature of most of the containers to maintain a pool for the stateless session beans, will work as static members. i.e..,as long as the same instance of the bean is being used between different calls you will see the value of the variable i changing every time you make a call.
This is because the container is given the definition that the bean is stateless and so it does not care about what is being stored in the bean and all it does is go and get the copy of the bean that is available. so if you are making calls to the bean in a sequence then there is a high possibility that same bean instance is being used for both the calls. so your variable value is retained from previous call and so it is incremented.
but the same thing if you declare the bean as stateful bean then the container makes sure the same copy of the bean is not being given to another client as now it has to maintain the state and so you will not see the value changing across different bean calls.

I dont know if i made it even more confusing .... but i will give you a piece of code which i was using to understand what is happenning.
////////////////////// My Public Methods /////////////////

public int square(int i){
return i * i;
}

public int add(int i, int j){
return i + j;
}

public int multiply(int i, int j){
return i * j;
}

public int multiplya(int a,int b){
product = a * b;
System.out.println("inside the bean. " + product);
return product;
}

public int getProduct(){
return product;
}

private int product;

This is the code same code that i have added both in the stateful and stateless bean
// Stateless Bean Client.

public static void main(String args[]) {

try{
InitialContext ctx = new InitialContext();
Object objRef = ctx.lookup("ejb/com/sbc/test/MySessionBeanHome");
MySessionBeanHome homeObj = (MySessionBeanHome)PortableRemoteObject.narrow(objRef,MySessionBeanHome.class);
MySessionBean actualBean = homeObj.create();


System.out.println("Hello the prod of 2,3 " + actualBean.multiplya(2,3));

objRef = ctx.lookup("ejb/com/sbc/test/MySessionBeanHome");
homeObj = (MySessionBeanHome)PortableRemoteObject.narrow(objRef,MySessionBeanHome.class);
MySessionBean actualBean1 = homeObj.create();

System.out.println("Hello the prod of 2,4 " + actualBean1.multiplya(2,4));
System.out.println("Hello the prod of 2,4 get product" + actualBean1.getProduct());


System.out.println("Hello the prod of 2,3 get product" + actualBean.getProduct());
}catch(javax.naming.NamingException ne){
ne.printStackTrace();
}catch(java.rmi.RemoteException re){
re.printStackTrace();
}catch(javax.ejb.CreateException ce){
ce.printStackTrace();
}
}


// stateful client.

public static void main(String args[]) {
try {
InitialContext ctx = new InitialContext();
Object objRef =
ctx.lookup("ejb/com/sbc/MyStateFulBean/StatefulHome");

StatefulHome homeObj =
(StatefulHome) PortableRemoteObject.narrow(
objRef,
StatefulHome.class);

Stateful myBean = homeObj.create();

System.out.println("Hello the prod of 2,3 " + myBean.multiply(2,3));

objRef = ctx.lookup("ejb/com/sbc/MyStateFulBean/StatefulHome");

homeObj = (StatefulHome)PortableRemoteObject.narrow(objRef,StatefulHome.class);
Stateful actualBean1 = homeObj.create();

System.out.println("Hello the prod of 2,4 " + actualBean1.multiply(2,4));
System.out.println("Hello the prod of 2,4 get product" + actualBean1.getProduct());


System.out.println("Hello the prod of 2,3 get product" + myBean.getProduct());

} catch (javax.naming.NamingException ne) {
ne.printStackTrace();
} catch (java.rmi.RemoteException re) {
re.printStackTrace();
} catch (javax.ejb.CreateException ce) {
ce.printStackTrace();
}
}
 
Don't touch me. And dont' touch this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic