JBoss Stateless Session Beans Implementation?

[siegfried1]

I was having trouble understanding what it means to pool stateless session beans.

When I complained to my collegue that there is nothing to pool because there is no state, he said not so: When I deploy a stateless session bean, an EJB container makes 60 copies of the executable code for that session bean and each pooled session bean points to its own unique read-only copy of the executable code.

Ughhh! I said. That is really ugly. He said Java does that for vendor neutrality!

Does JBoss optimize this so that everyone uses the same copy of session bean so there is no pooling of stateless session beans?

Thanks,
Siegfried

[jonlee]

When we talk about pools of stateless session beans, we are talking about a collection of class instances. This is no different from the standard model of Java. And like standard Java, creating instances of a class is expensive - more so in the EJB world as there is the underlying problem of providing the networking hooks and so on.

At any point in time, a particular instance of a class will have a different local state - local variables set as a result of the client call. Again, this is no different to normal Java. You can create multiple instances of a class within a program and each will have different local information.

So pooling stateless session beans is a means of avoiding the expense of creating instances of the bean. For the same reason, we pool database connections so we can avoid the expense of creating a new connection to the database every time we want to use the database.

It is unlikely that you will have a pool of stateless session beans reach a size of 60 unless your methods have very intensive processing incorporated in them. A typical stateless session bean should perform a quanta of work over a very short amount of time and then be recycled. If it is not, then you should consider a redesign using other EJB types, other J2EE infrastructure or other decoupling mechanisms.

Typically, an instance of the stateless session bean is created (a pool of one, although some containers don't create a pool until there is demand for the bean) and the pool grows and shrinks as demand for the resource dictates. With some containers, you can govern this by setting a predetermined minimum and maximum pool size. This helps ensure that your application remains responsive for bursty access and governs resource use under extreme load. The nice thing in JBoss is that this is the deployment engineer's problem rather than the application designer's.

Hope that helps.

[siegfried1]

Do stateless sessions beans have state?

If not, what is the difference between the static functions of a stateless session bean and the non-static (regular) functions?

Hmmmm.... I see one difference: static functions don't require I have an instance of the class! If you have a stateless object, why would anyone want to waste the overhead of creating an instance of it?

When they created the EJB specification, why didn't they require all session beans to be implemented exclusively with static member functions?

[haraldgliebe]

Yes, a stateless session bean may have state, e.g. a connection to a database. What distinguishes them from stateful session beans is that their state is not specific to the client of the bean.

The EJB spec additionally guarantees that an instance of a session bean is accessed single-threaded, therefore an EJB container will usually create multiple instances of a session bean to handle multiple clients concurrently.

Regards,
Harald