File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Confused with Stateless Session Bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Confused with Stateless Session Bean" Watch "Confused with Stateless Session Bean" New topic
Author

Confused with Stateless Session Bean

Faber Siagian
Ranch Hand

Joined: Jul 08, 2008
Posts: 52
Dear Ranchers,

I have a simple program to show the difference between stateless and stateful session bean :

Business Interface :



Bean Class :



The idea behind code above is returning counter from EJB to servlet and display it by using JSP.
Because the bean class is stateless, I expect the counter will always zero, just as
stateless session bean does not maintain a conversational state with the client.

But the result shows something different. The counter gets incremented each time I refresh the page.

Would someone explain what's wrong here ?


Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0 (88 %)
Edvins Reisons
Ranch Hand

Joined: Dec 11, 2006
Posts: 364
Try it with two clients
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9500
    
    2

Since your refreshes are spontaneous, the instance is not requested from the pool everytime and the same instance serves you the result which gets incremented each time you refresh. Use a timeout method and return the instance to the pool and then refresh the page again and you will find that it again sarts with 0.

As the previous post mentions, you cannot guarantee that if you call from a different client, you will get to see a different number for the counter. You will for sure see the intial counter value only when the instance is loaded into the memory from the container's pool.


SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
Faber Siagian
Ranch Hand

Joined: Jul 08, 2008
Posts: 52
Originally posted by Jothi Shankar Kumar Sankararaj:
Since your refreshes are spontaneous, the instance is not requested from the pool everytime and the same instance serves you the result which gets incremented each time you refresh. Use a timeout method and return the instance to the pool and then refresh the page again and you will find that it again sarts with 0.


So you said that an instance of stateless session bean will be stored in the pool?
I read a book who says that stateful session bean will be stored in a pool meanwhile stateless won't. Correct me if i'm wrong.
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9500
    
    2

When there is no pooling mechanism in a container for Stateless session bean, then I will never use that container.

The specification says that the container must maintain equal instances of Stateless session beans in the pool. And as for Stateful session beans are concerned, there will be unequal instances in pool...one for each client.
Faber Siagian
Ranch Hand

Joined: Jul 08, 2008
Posts: 52
Actually I expect this scenario :

After the user's request completed, the stateless session bean instance is moved into pool thus the value of counter reset. This is the real "stateless" session bean to me.
Edvins Reisons
Ranch Hand

Joined: Dec 11, 2006
Posts: 364
Moving the bean into the pool does not reset its member variables.
So, the counter will increase with each method call, no matter which client calls it.
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9500
    
    2

Originally posted by Edvins Reisons:
Moving the bean into the pool does not reset its member variables.
So, the counter will increase with each method call, no matter which client calls it.


The specification says equal instances of Stateless beans must exist in the pool which means all the state values for different instances must be equal.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


The specification says equal instances of Stateless beans must exist in the pool which means all the state values for different instances must be equal.

Equal instances? Not sure I follow what you mean by this. Containers are not required to propegate changes to member variables around the various instances. That is, at least as far as I'm aware - which section of the spec. defines this?


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9500
    
    2

So in the example above, a new client requests for a SSB instance and the container allocates one form the pool and which has a value of 5 (for example) for one of its instance field and another client request for another instance and say the client allocates another bean from the pool whose value for the same instance field is 0...is this situation allowed?
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Yes. Think about it. The container can respond to a request for an EJB by instantiating a new instance of the stateless session EJB or using an existing one. If its a new instance the member variable has not been initialised. If its an existing one the member variable has and it has been incremented n times. Any state saved in a specific instance is therefore not reliable. If you need such state, a stateful EJB is the one you need.
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9500
    
    2

Originally posted by Paul Sturrock:
Yes. Think about it. The container can respond to a request for an EJB by instantiating a new instance of the stateless session EJB or using an existing one. If its a new instance the member variable has not been initialised. If its an existing one the member variable has and it has been incremented n times. Any state saved in a specific instance is therefore not reliable. If you need such state, a stateful EJB is the one you need.


I accept, but what happens when the container returns the instance that has its instance variable n times initialized to the Stateless bean pool?
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

The instance isn't removed, so I'd imagine its state is unchanged. But then again, why does it matter? My point is state in stateless code can't be trusted, so don't use it.
[ September 26, 2008: Message edited by: Paul Sturrock ]
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9500
    
    2

Originally posted by Paul Sturrock:
The instance isn't removed, so I'd imagine its state is unchanged. But then again, why does it matter? My point is state in stateless code can't be trusted, so don't use it.

[ September 26, 2008: Message edited by: Paul Sturrock ]


You are right paul, using a state in a stateless bean is pointless and untrustworthy but why can't the container when getting the instance back to the pool make the state which was initialized n times, to a default value?
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


You are right paul, using a state in a stateless bean is pointless and untrustworthy but why can't the container when getting the instance back to the pool make the state which was initialized n times, to a default value?

How would the container work out what to do? Suppose your member variable is initialised in ejbCreate to a value and nothing else changes it, how does the container reset this? Again though, why should it even be trying? Its reasonable to assume that people developing EJBs understand their restrictions (since they are written down in a specification this is reasonable) so why should EJB containers do any extra to work round the possibility of someone missusing an EJB?
vincent mark
Greenhorn

Joined: Oct 20, 2008
Posts: 1
This post has been very helpful in understanding it. So from what I understand, a pool of stateless beans can have different values for instance variables, if a user chooses to change these instance variables. Did I understand it right ?

I have been trying to implement a stateful webservice. After reading several blogs ( http://weblogs.java.net/blog/kohsuke/archive/2006/10/bringing_state.html ), I understand I can do that using either WS-Addressing or HTTPSessionScope. I chose to use HTTPSessionScope, bcz. WS-Addresing option was not working.

The above link says, @HttpSessionScope will cause to create different instances of "Hello" (a stateless EJB, as I understand) for each client. I am still seeing the same instance of stateless bean from different client.

What I am not understanding correctly here ? Any help will be great !

Thanks
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30916
    
158

'vmWS",
Please check your private messages about an important administrative matter.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Confused with Stateless Session Bean