• 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

difference between stateless and stateful session bean

 
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Anybody knows the difference is can/cannot keep client state. the problem is what is the "state"? where to keep the "state"? my point is all state objects are referred by session bean's member fields and kept. from caller point of view, there is no big different.
There "real world" difference is:
1.when we use stateless, we look up the bean, call a method, we give up the bean reference, the bean return to pool;
2.when we use stateful, we look up the bean and keep the reference for a long time(may several minutes to hours, say shopping cart), we call methods sometime. if we use stateless, each client will always associated one bean in memory, it costs a lot! for stateful, we don't need to worry about it too much, the container will passivate some of them to disk when resource is not enough. I think it is the real benefit of stateful session bean.
Any different thoughts?




:roll:
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One more question:
Say I have a BMT stateful session bean, transaction is started in one method but closed in another, what is the transaction status of my calling client between several calls to the bean methods? I may don't have transaction at begining or have, there may have some exceptions out from the client code between 2 bean calls...
I nned your help, thanks in advance.
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Using SLSB are actually considered to have better performance than to use SFSB. For SFSB, each bean is tied with its client. Passivation mechinizm is just an indication of its weakness. Normally, the number of SFSB will be at least as big as the number of the clients that is using the SFSB. For SLSB, with pool, the number of bean is much less than the number of clients.
As for transaction for BMT SFSB, the BMT bean always suspend the client transaction before it starts its own transactions. Therefore the BMT's transation shouldn't affect the clien'ts transaction statues. However, I don't know how client's trasaction is resumed when an exception is thrown inside a BMT bean initiated trasaction. I GUESS, if client catch the exception the client should examine its transaction status and decided to abort the trasaction or not.
 
Jack Zhou
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

where to keep the "state"? my point is all state objects are referred by session bean's member fields and kept. from caller point of view, there is no big different.


In the perspective of an java object both SLSB and SFSB has states.
the "stateless" vs "stateful" refers the "conversational" states.
suppose you have a SLSB OrderManager. It is a field currentOrder with its
setters and getters. With the SLSB, if you have the following calls:

now it is not gurantted that order and myorder represents the same order object.
But if it is a SFSB, it is you can expect the order object for getter is the one you have passed in to the setter.
In theory, if you only call the SFSB only once in its life time, then your SFSB will just function as a SLSB. But then, you should use SLSB for performance reason.
 
reply
    Bookmark Topic Watch Topic
  • New Topic