• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SLSB & SessionSynchronization interface

 
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Page 253, answer to the question 7 of the mock exam says that, "A Stateless session bean cannot implement the SessionSynchronization interface". I don't understand why it is like this? I know, spec also says the same. But, is there a logical reason associated with this?
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ankit,
Consider scinario of any shopping cart. The obvious choice for it is stateful session bean. User adds item A in cart, then user adds item B in cart. But when user is trying to add item C into cart some run time exception occurs. The desired beahaviour for the application to restore the state to the cart with items A and B in it. This can be achieved with SessionSynchronization interface. Without this user need to start all over again.
This is not required for stateless session beans because, they do not hold user conversation state between method invocations. If we implement the above example with stateless beans then client always need to pass the current state information. Means as method parameter client will pass how many items it has in the cart. So even if transaction is rolled back while adding item C you still have A and B in virtual cart. As you do not have any user state there is no point in implementing SessionSynchronization interface.
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does that mean that the stateless session beans don't need transaction at all?
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ankit Doshi:
Does that mean that the stateless session beans don't need transaction at all?



No, SessionSynchonization is for synchronizing purpose, hence stateless session bean don't need to implement it because stateless session bean don't have state. Furthurmore, for BMT stateful session bean you begin and commit transaction yourself therefore there is no need to use SessionSynchronization.

In conclusion only CMT stateful session bean may implement SessionSynchonization.
 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Consider scinario of any shopping cart. The obvious choice for it is stateful session bean. User adds item A in cart, then user adds item B in cart. But when user is trying to add item C into cart some run time exception occurs. The desired beahaviour for the application to restore the state to the cart with items A and B in it. This can be achieved with SessionSynchronization interface. Without this user need to start all over again.



How could you restore the bean??? This is not an entity bean.
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kengkaj Sathianpantarit:


No, SessionSynchonization is for synchronizing purpose, hence stateless session bean don't need to implement it because stateless session bean don't have state.



Ok, I understand that since SessionSynchronization is mainly for synchronizing the state and since the SLSB doesn't maintain any state hence they don't need to implement the SessionSynchronization.

But I am still confusing on why would the SLSB need to manage transaction? Probably what I understand is that, transaction management is only important when the transaction has to span over multiple methods.

Can someone give me a example scenario wherein a problem would occur in case the SLSB is not associated with any transaction?
reply
    Bookmark Topic Watch Topic
  • New Topic