About not using SFSB...

Last friday a light conversation about how to design the Hermes application took place. One point was about not using SFSB's at all, just stateless session beans. If no any SFSB is used in the project, some stuff comes to my mind:

• On the booking example can be read the following (view/exp/bookingExp.html):

  
  

  
  
  The hotel booking "wizard" is implemented by a conversation-scoped stateful session bean. All Seam components are in the conversation scope by default. The HotelBookingAction maintains state associated with the booking process in the Seam conversation scope. This ensures that if the user is working in multiple brower tabs or multiple brower windows, the various conversations are completely isolated from each other.
  

  
  

  
  By not using SFSB's ¿will we miss the ability to mantain the state associated with the booking process in the seam conversation scope?
  

  
  



• The idea of an application transaction with optimistic semantics, and the realization that existing frameworks based around a stateless architecture could not provide effective management of extended persistence contexts. (The Hibernate team is truly fed up with copping the blame for LazyInitializationExceptions, which are not really Hibernate's fault, but rather the fault of the extremely limiting persistence context model supported by stateless architectures such as the Spring framework or the traditional stateless session facade (anti)pattern in J2EE.)

  
  

  * extracted from Conversations and workspace management (Seam_Reference_Guide.pdf)