This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Five Lines of Code and have Christian Clausen on-line!
See this thread for details.
Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring 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 ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Qtn regarding setSessioncontext

Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,
I need clarification regardiong setSessioncontext. I don't understand if in

1. setSessionContext if we can get a reference to EJBHome why not get security information about the client?

2. If we can have special JNDI access like datasource and by uising it If I get ds.getConnection, why I cannot able to use the connection. Does it stops me to do con.createStament() and executng query.

If you have any clarification things pls. help me out. Thanks !
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Shankar

For stateless session beans a part of a explanation for question 1 and 2 is that setSessionContext (and ejbCreate) is called by the container when the stateless session beans moves from the state �does not exist� to the state �method-ready pool�, this state transition is not triggered by any client call (see page 89 in the specification). I.e. you have an unspecified transaction context and there is no client to get security information about.

For stateful session beans I think that the spec gives a part of an explanation to your second question in a note on page 76

The ejbCreate and ejbRemove methods are not controlled by a transaction attribute because handling
rollbacks in these methods would greatly complicate the session instance�s state diagram.
setSessionContext is called by the container before ejbCreate so the reasoning in the quote above must apply here as well.

With out the spec actually saying so I get the impression that this note is the explanation for your question as well. I guess the restrictions mentioned in your question apply because otherwise it would make the state diagram of a session bean to complicated. new instance, setSessionContext and ejbCreate are all called in serialization in the state transition from �does not exist� to �method ready�. E.g. in the stateful session bean state diagram on page 77 in the specification you would have to introduce some additional state like �security context ready� before the call to setSessionContext if it should be allowed to access client specific security information in setSessionContext.

Kind regards
Natarajan Shankar
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Christina,
Thanks a lot for your explanation, I was looking for any specific reason for not able to access the method. From your explanation i understood thre might some more extra features need to be added from by container providers.

Thanks for sharing your knowledge.
Because those who mind don't matter and those who matter don't mind - Seuss. Tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic