Enthuware

Hi,

I know that per specifications a stateless session bean must not implement the SessionSynchronization interface, but could you explain to me why ?

Thanks in advance.

Because a stateless bean has to start and complete a transaction in the same method. So it always knows when the transaction begins (at the start of the method) and when it ends (at the end of the method.). So there is no need for it to implement this interface.
A stateful bean doesn't know that because a transaction could have been started by some other method in another call.

Similarly, the specification explains the same thing in section 4.3.7 for bean managed:

There is no need for a session bean with bean-managed transaction demarcation to rely on the synchronization call backs because the bean is in control of the commit—the bean knows when the transaction is about to be committed and it knows the outcome of the transaction commit.

HTH,
Paul.

But for CMT stateful session beans also the transaction begins at the start of the method and ends at the end of the method. so we know the boundaries of the transaction

In a CMT bean the transaction is controlled by the container, while in a BMT it is the bean that starts or completes the transaction. Now, what is the point of notifying someone that a transaction has started, when that someone itself has started it?
In case of a stateless bean, a container can have multiple instances. A container can use one instance to serve one method call and another to serve another call. Now, when a transaction is started by the container for a client, which bean instance will the container notify? Remember that there is no particular bean instance associated with a client.

OTOH, only a single stateful bean instance is attached to a client. So there is exactly one instance that the container has to notify when a transaction is started/finished.

regarding the first point, I already agree that there is no need for SessionSynchronization for BMT's.
Now, For CMT stateless beans, I like the way you saw that, but what I can't understand is that SessionSynchronization are callbacks and they act like interceptors, how the container know to associate interceptors and lifecycle callbacks to a stateless bean even if there is many instances. I think that SessionSynchronization normally act like that. don't you agree ?

NB: By the way, I started also a thread on stackoverflow regarding that, as I feel that I already bothered you a lot, and this is out of the scope of the question.

Life cycle and other interceptor callbacks are for a particular instance. So there is no problem in associating.

Sorry, but I don't understand your point Paul, why you said Life cycle and other interceptor callbacks are for a particular instance while SessionSynchrinization methods are not?

Well, if an instance is created, then it is that instance on which Post-construct will be called, right?
txn is for a client, and no specific stateless bean instance is associated with a client.

I can't agree with that, even if tx is associated with a client, its the container whi will start the transaction.
I will tell how I see things, and please tell me what is wrong in that:
a client call an SLSB business method, and the container starts a transaction on a random instance from the pool, the container can pick any instance and call afterBegin() (for example), then he will start the business method, after method complete he will call beforeCompletion() (like any interceptor method for example)....

Interceptor methods are acting like that, so its very difficult to me to beleive that its impossible for SessionSynchrinization to act like an interceptor class.

Well, that is the logic that I gathered by the reading the specification. I agree that it may be somehow technically possible. Logically though, I agree with the specification that the txn and a stateless bean instance are not tied.