Confused with Stateless Session Bean

[Faber Siagian]

Dear Ranchers,

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

Business Interface :

@Local
public interface SelectFacadeLocal {
    public int getLatestCounter();
}

Bean Class :

@Stateless
public class SelectFacadeBean implements SelectFacadeLocal {
    
    private int counter;
    
    public int getLatestCounter() {
        return ++counter;
    }
}

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 ?

[Edvins Reisons]

Try it with two clients

[Joe San]

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.

[Faber Siagian]

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 San]

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]

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]

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 San]

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]

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?

[Joe San]

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]

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 San]

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]

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 San]

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]

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]

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]

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