• 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

Operation Allowed in Stateless and Stateful Bean

 
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Look at the specs carefully with regards to the operations allowed in methods of Stateful and Stateless beans on page 79 and 88 of core ejb.

If you check the operations allowed in the lifecycle callback methods in both cases one thing appears quite weird which is:

PostConstruct, PreDestroy of Stateful beans can have access to almost all operations such as Resource Manager, EntityManager, EJB, UserTransaction(in BMT). But these are not allowed in PostConstruct and PreDestroy of Stateless beans.

Why is this so?
 
Ranch Hand
Posts: 244
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I had noticed such a thing. I think it is due to the fact that stateless session bean are pooled, so the invocation of those methods happen without a security/tx context.
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Interesting point, but I think the situation is quite different.
I'm guessing the reason is something like this:

Only in stateful session beans can the transactions and persistence contexts span multiple business invocations.
In stateless beans you will have to commit all changes before the end of a business method.
In stateful beans you may wait with this kind of behavior until the bean is removed for performance reasons.
You can have multiple @Remove methods, so I guess @PreDestroy is more convenient, as there is at most one.
If we take all this into account, then you will need access to the EntityManager, the UserTransaction and the ResourceManager here.

Similarly there is no client in the @PreDestroy of a @Stateless session bean, so you can't access the principal as in @Stateful.
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Statefull session bean will be created after client invoke the Business interface
BUT Stateless session will be created by container and available in POOL regardless of client
[ July 08, 2008: Message edited by: John Kristin ]
reply
    Bookmark Topic Watch Topic
  • New Topic