• 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

Qtn regarding setSessioncontext

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 !
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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

quote:
---
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
Christian
 
Natarajan Shankar
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic