Stateless session beans and Transactions

[KRK Gowda]

Hi All,
Can you tell me can we run stateless session beans within transactions? If yes, what are its benefits?
Is it really required to run stateless session beans within transactions?

Thanks and Regards,

[Benoît de Chateauvieux]

Yes, we can run Stateless Session Bean within Transaction.
The benefits of the transaction reside in his four characteristics:
- Atomic
- Consistent
- Isolated
- Durable

You can run a Stateless Session Bean in a Transaction or no.
This can be set with the @TransactionAtribute anotation (wich can be applied per method o per bean).

[Camilo Morales]

Right, also, the main difference about Transactions between Stateless and Stateful session beans is that ONLY Stateful session beans can have EXTENDED persistent context.

This is because we can be sure that every method invocation on a statefull session bean will be using the same instance for the same client ,,, but in the case of stateless session beans, there is a pool of instances and hence we can not be sure that the next method invocations will be using the same instance as the first method, so the transaction of the first method can not be "extended" to the second method since the container cant be sure they are call in the same instance.

[KRK Gowda]

Thanks camilo,
But, as for as i know, container cannot move the bean instance to does not exists state, unless the transaction comes to end.
If we configure a transaction on a bean instead of a method of the bean, then that bean will be in method ready state will be present in the same state,till the transaction is not closed. Dont you think even stateless beans can also have extended persistent state in such scenario?

[Camilo Morales]

Originally posted by KRK Gowda:
Thanks camilo,
But, as for as i know, container cannot move the bean instance to does not exists state, unless the transaction comes to end.
If we configure a transaction on a bean instead of a method of the bean, then that bean will be in method ready state will be present in the same state,till the transaction is not closed. Dont you think even stateless beans can also have extended persistent state in such scenario?

No, and here is why:

First, What do you mean "If we configure a transaction on a bean instead of a method of the bean". Sorry for my igorance, but all I can think after reading that statement is that you are refering to using the @TransactionAttribute annotation at bean class level, which only means that it applies to all applicable business interface methods of the bean's class. The methods of the Bean may be transactional ,,, BUT NOT the beans itself, or at leats I dont know what that could mean.

But, as for as i know, container cannot move the bean instance to does not exists state, unless the transaction comes to end.

To start, you must consider that stateless session beans are managed by the containers using pools of instances. Now, when a client calls a method of a stateless sesison bean, the container use ANY of the instances in the pool to service that request, and when the request is complete (the method comes to end) the instance is returned to the pool. So, stateless session beans DO NOT maintain state between method invocations. So, considering that EXTENDED PERSISTENCE CONTEXTS propagate the SAME TRANSACTION SCOPE to MANY METHOD INVOCATIONS, stateless session beans can not declare EntityManagers that use EXTENDED Persistence Contexts.

Here is a paragraph of Enterprise Java Beans 3.0 (O'Reilly) that may be a lot more clear about what I am trying to say:

Because a stateless session bean does not maintain any state between method invocations, every method invocation operates independently, performing its task without relying on instance variables. This means that any stateless session instance can service requests for any EJB object of the proper type. The container can therefore swap bean instances in and out between method invocations.

Each EJB vendor implements instance pooling differently, but all instance-pooling strategies attempt to manage collections of bean instances so that they are quickly accessible at runtime. To set up an instance pool, the EJB container creates several instances of a bean class and then holds on to them until they are needed. As clients make business-method requests, bean instances from the pool are assigned to the EJB requests associated with the clients. After the request is complete, the EJB object doesn't need the instance anymore and it's returned to the instance pool. An EJB server maintains instance pools for every type of stateless session bean deployed. Every instance in an instance pool is equivalentthey are all treated equally. Instances are selected arbitrarily from the instance pool and are assigned to EJB requests as needed.

It also says in the Chapter 11.6 (Stateful Session Beans and Extended Persistence Contexts):

Stateful session beans are the only EJB component type that is allowed to inject an EXTENDED persistence context through the @PersistenceContext annotation.

Because a stateful bean represents a conversation with a client, it makes sense to cache and manage entity instances across method invocations. Stateless and message-driven beans are pooled, and managed entity instances would easily become stale and unusable.

Please correct me if I'm wrong.