setSessionContext method

[Srinivasan Rengan]

Hi All,
I have this small little doubt in stateful session bean. When we are able to access the client related security info in ejbCreate method, why are we not able to do the same in setSessionContext method. One reason which I found in one of the thread was, that the EJBObject is bound to the context only when ejbCreate is called. But, what difference will this make. Are we to understand that, only when the reference to the EjbObject is inferred, we can take advantage of the services of the container, which would enable us to get the security information about the client.

Thanks in advance!
[ April 25, 2006: Message edited by: Srinivasan R ]

[Ernesto Elias-Nieland]

Hi!

The reason is that there is no client from which you can get security informations in setSessionContext for stateless session beans, because the bean is created when the container wants to enlarge the pool. And because there is just one interface for stateless and statefull session beans, you can't be shure if there is a client.
But if think you are able to call the security related methods. You just get an Exception.

Ernie

[Srinivasan Rengan]

Thanks Ernesto Elias-Nieland.
But, I need this clarification with regard to stateful session bean.

Srini

[Ankit Doshi]

This is what I understand:

If you are using HFEJB, look at the diagram on page 193. Container links the bean to its context and EJBObject by calling the setSessionContext() and ejbCreate() on the bean instance. After setSessionContext() is called, the bean is linked to it's SessionContext instance, but, at this point of time, the bean is not yet linked to it's EJBObject. This will be linked only during ejbCreate().

EJBObject is the one who interacts with the client, so if the bean is not linked to the EJBObject at all, how is it going to get the client security information?

[Srinivasan Rengan]

Hi
Can some one add more inputs to this...
:roll:

[Ankit Doshi]

Think of this from the point of view of the container. Let say you are going to implement the container services - then how are you going to implement this?

You basically need to figure out, exactly when your EJBObject is going to be linked with the bean instance. And before this linking happens, if the bean code tries to access the client security info, how are you going to make that info available?

Does this make sense?

[Srinivasan Rengan]

Thanks Ankit.
In case of stateless session bean, why are we not able to get the security information in the ejbCreate method. Because, as we know, ejbCreate would be called when the bean is binded with the Remote object and the session context object. The fact that, there is no client in this case is evident. But, as we have the remote object, which has been created due to the call from a client, makes it clear that remote object knows the client. Thus, why are we not able to get the
security info.

Thanks
Srini

[Ankit Doshi]

Hi Srini,

It's very simple in case of stateless session bean. For stateless session bean, the client invocation of create method and the invocation of the ejbCreate method are NOT related.

The bean instances are created by the container when the container wants to add new bean instance to the pool - by calling constructor, then setSessionContext and then ejbCreate. And as there is no client here, you can't get the client security info.

[Srinivasan Rengan]

thanks ankit. I think that's convincing.

[Rizwan Mohammad]

Hi Srini,
In case of stateless session beans, no client is associated to any session bean when ejbCreat is called. This is very clear.

In case of stateful session beans by setting session context, instance will not get bean-ness unless its ejbCreate() method gets called. Though client is known to container by that time and techincally you can get security information. Logically it is not yet achieved its bean-ness(as you haven't had proper initialization).. So spec has prevented to mis-use of EJBContext methods which are globally shared by all types of beans at variety of situations.
for e.g. This is the one.. you cannot ask security info from a not yet initiazed bean, just having session context. It said to be complete only when it has both session context and intialization(ejbCreate). You can assume ejbCreate as a kind of second and important constructor of stateful session beans. For entity beans its altogether different story.

HTH.

[Srinivasan Rengan]

Hi Rizu. Nice to c u after a long time.

Thanks for your apt reply.
But, I am not getting it clearly. When will ejbCreate method be called during the life cycle of a stateless session bean? In other words, will ejbCreate method be called when the client calls the create method and thus creating the EJBObject (or) is it during the business method call of the client, where the bean is bound to the EJBObject.

Another significant point, which I wish to clarify is that, in case of stateful session bean, we will not be able to call methods on the (BMT) transaction object. Why is this? But, we will be able to do the same thing in the business method. What determines the access to the transaction method access?

Thanks:

[Rizwan Mohammad]

Hi Srinivas,
Sorry for late reply.
In case of stateless session bean actual bean creation happens completely different time than you call business method. Container can create actual stateless session bean anytime(mostly when container starts) during its lifetime. When it creates SLSB, it calls constructor, sets session context and calls ejbCreate method and puts that object in pool. When user calls create() method on SLSB, container never creates bean it simply creates EJBObject and returns it to client. When client actually calls business method on SSLB, container links between EJBObject and actual Bean. And immediately after the method call completes, EJBObject is disconnected with Bean and bean goes back to pool. Thats why you cannot get security info, transaction info in create method of SLSB, which happens in complete different time than client calls.
I am not sure what u are asking on BMT? but again if you understand the difference between life cycles of SLSB and SFSB(if not read ch:4 of HFEJB)
you will be able to see clearly what methods you can call in which method.
you cannot call transaction related(BMT) methods in create method of SLSB but you can call in create method of SFSB as create is associate to client in case of SFSB. But you can call transaction methods in any type of bean in business methods.
HTH.