Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

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

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Foreman
Posts: 1924
13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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
Ranch Foreman
Posts: 1924
13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Foreman
Posts: 1924
13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Foreman
Posts: 1924
13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
    Bookmark Topic Watch Topic
  • New Topic