• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

setSessionContext and things you can do

 
jeff mutonho
Ranch Hand
Posts: 271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the setSessioContext() method for a Stateful session bean , we can use the SessionContext referenec to get a reference to a bean's home.Why is it not possible get security information about the client at this stage?For the container to start creating the bean , a client would have invoked create() on the home.
Is it just because the spec says so?

jeff mutonho
 
B.Sathish
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff,
Whenever you come across a discrepancy like this in "Bean Things", don't get too alarmed or think that you have not understood something properly. Think --> "This discrepancy could be because the EJB specification is not rigid when it comes to container implementations and it provides a lot of room for containers to optimize thier implementations"

In this case, because it is not necessary to get client security information in the setSessionContext() method, the containers can choose to pre-create the bean object and the session context obect and run the bean constructor and setSessionContext() methods even before the client calls create. When the client calls create(), it can just run the ejbCreate() method. What's the advantage of doing this? Faster response when the client calls create.

Now I know what you are thinking. The Object Interaction Diagram given in the book says that setSessionContext() would run only after the client calls create. Well, as a bean developer, you are supposed to write code assuming that this is how it works. But as far as the container implementation is concerned, the spec does not lock down things saying that this is how it MUST work. By not locking down that way, containers can improvise their implementations to provide faster response and compete for the market. The spec designers would have had a tough time deciding where to draw the line so that the spec is standard enough so as not to confuse the bean developers and at the same time not so rigid as to lock down container implementations.

As a bean developer, why should you worry about all this. Because it affects what you can and cannot do in variuos methods.

For the exam, my advice would be to learn "Bean Things" by heart without looking too much into it. yeah it sucks a bit, but it's the best way
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic