How is the transaction boundary in Stateful-SB with CMT decided?

[You Peng]

Hi there,

The transaction boundaries in Stateful-SB with BMT and in Stateless-SB/MDB/Singleton-SB with CMT are both easy to understand. But it's rather confusing to me how the boundary is decided with Stateful-SB with CMT.
On the one hand, it seems the transaction boundary doesn't naturally match method boundary, as in other session beans with CMT; (if they match, then implementing SessionSynchronization doesn't seem to make much sense)
on the other hand, it's still managed by the container and not by user, as with BMT.

Could someone please help?

Thanks a lot!
You

[Himai Minh]

how the boundary is decided with Stateful-SB with CMT

With CMT, a transaction is committed before a business method completes.

implementing SessionSynchronization doesn't seem to make much sense

SessionSynchronization is used when BMT is used.

[Himai Minh]

Let me correct my post. SessionSynchronization is only implemented by CMT stateful bean.

You may find this previous post helpful"
https://coderanch.com/t/161504/java-EJB-SCBCD/certification/Session-Synchronization

[Himai Minh]

Typically, the container begins a transaction immediately before an enterprise bean method starts. It commits the transaction just before the method exits. Each method can be associated with a single transaction. Nested or multiple transactions are not allowed within a method.

Reference : https://docs.oracle.com/javaee/5/tutorial/doc/bncij.html

[You Peng]

Himai, thanks for your reply.

SessionSynchronization is used when BMT is used.

A stateful session bean with container-managed transaction
demarcation can optionally implement the javax.ejb.SessionSynchronization
interface or use the session synchronization annotations.
[from EJB3.1 Specification 13.3.4.1]

With CMT, a transaction is committed before a business method completes.

This is true with CMT in Stateless-SB and in Singleton-SB. But these beans cannot implement
SessionSynchronization, while Stateful-SB can [from EJB3.1 Specification 4.3.7].
I guess there should be a reason for such a difference.
If the transaction boundaries also match method boundaries, then everything we can do with
the SessionSynchronization interface can also be done using interceptors. Then what's the point of
this interface?

After another thought, maybe the point of the interface is just to provide a means to
act at transaction boundaries, without having to add interceptors to all methods in
bean's views.

[You Peng]

Himai Minh wrote:You may find this previous post helpful"
https://coderanch.com/t/161504/java-EJB-SCBCD/certification/Session-Synchronization

Thanks, it is helpful.

[Himai Minh]

If the transaction boundaries also match method boundaries, then everything we can do with
the SessionSynchronization interface can also be done using interceptors. Then what's the point of
this interface?

After another thought, maybe the point of the interface is just to provide a means to
act at transaction boundaries, without having to add interceptors to all methods in
bean's views.

Those methods from SessionSynchronization interface or @AfterBegin, @BeforeComplete... methods are interceptor methods that are called when a transaction begins, after a transaction completes (eg committed or rolled back) , before a transaction commits.

We need these methods because we need to synchronize the client specific instance variables of stateful beans with the database. The instance variables may be used across all business methods. That is why we need to synchronize the data with the database.

We don't need these methods for singleton/stateless because their instance variables are not client specific.
The instance variables should not be used across all business methods. A variable which is set in one business method is not guaranteed to be the same in the next business method call.
For example, update the database using the variable before the method exits. Don't use this same variable for the next method call and update the database with the same variable.
That is why we don't need to synchronize the data with the database for singleton/stateless beans.

[You Peng]

Those methods from SessionSynchronization interface or @AfterBegin, @BeforeComplete... methods are interceptor methods ...

Exactly. The more I think about it, the more I feel they are just mechanisms to facilitate intercepting all the interface methods in the bean's view.