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
