Win a copy of Mastering Corda: Blockchain for Java Developers this week in the Cloud/Virtualization 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 ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

ejbRemove access to client info after a timeout

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,
One of the reasons we can�t access client info from the SessionContext object in an ejbRemove for an stateless session bean is that this callback is not triggered by means of the client, and so it does not make sense, since there is no client involved.
But for stateful session beans there is a circumstance under which the ejbRemove is triggered without the client calling remove explicitly, and it is when the bean times-out in the active state.
In this situation, how is the container supposed to provide the client info? Should it keep this info from the last business method call made by the client?
According to the specs (7.6.1), the methods getCallerPrincipal and isCallerInRole are callable from ejbRemove.
These questions also apply to the ejbPassivate method, that is also triggered by a timeout, and not directly by the client.
Constantino
[ March 03, 2004: Message edited by: Constantino Cronemberger ]
 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is implementation dependent. A bean provider doesn't need to care about this. The point is: a stateful session bean is ALWAYS tied up with a client until after it is removed (including time out and runtime exception).
 
reply
    Bookmark Topic Watch Topic
  • New Topic