This week's book giveaway is in the HTML Pages with CSS and JavaScript forum.
We're giving away four copies of Testing JavaScript Applications and have Lucas da Costa on-line!
See this thread for details.
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 ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Session Synchronization

Posts: 3036
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to "Heads First EJB" (p. 513):

Only stateFUL session beans can implement SessionSynchronization, because stateless session bean's (sic) aren't allowed to maintain a transaction once a method has ended.

and also:

SessionSynchronization is for CMT beans ONLY!

However, only BMT Stateful Session Beans are allowed to maintain a transaction once a method has ended. That's a conflict in logic isn't it? Is it a conflict in the EJB 2.0 spec, in the book's explanation, or is one of the claims actually not true?
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would say that is improper reasoning in the book.

You can understand it this way. SessionSynchronization - it's purpose is to notify the bean about important moments in its transactional life so that the bean can synchronize the state that it is maintaining on behalf of the client with the database. For example, when the transaction begins (afterBegin), the bean can load its state variables with data from the database to be used for the whole transaction, when the transaction is about to complete (beforeCompletion), it can update the database with the state of its variables and after the transaction completes (afterCompletion), it can do what ever it needs to bring its state variables to sync with the database, for example, if the transaction rolled back, it might have to reset its state variables with the old data to bring it in sync with the database. Hence, you are basically using the bean as a poor-man's entity bean. If it is a stateless session bean, it does not have any client-specific state right? Then what will you synchronize? So stateless session beans cannot implement SessionSynchronization because they do not maintain any client-specific state in the first place that would need synchronization.

If you have a BMT bean, the bean is controlling the transaction. The bean knows exactly when the transaction begins and ends. But for a CMT bean, because the container is controlling the transaction, it will not know when the transaction begins and ends unless the container notifies it which it does through the Session Syncronization callbacks. As a BMT bean already knows everything about the transaction, it does not need any transaction related notifications and hence it is meaningless to have it implement the SessionSynchronization interface.

Hence SessionSynchronization is only for stateful CMT beans
    Bookmark Topic Watch Topic
  • New Topic