getEJBObject in setSessionContext

[Shiang Wang]

EJBObject already exists in the container before setSessionContext() is called, why can't I call getEJBObject() on SessionContext in setSessionContext?

When the client calls create<Method> on home interface.
1.container makes the EJBObject
2.container sends the client a stub of EJBObject
3.container constructs the SessionContext object ( and the bean instance if it is a stateful bean)
4.container calls setSessionContext on the bean.
5.container puts the bean in the pool for that bean type

Also, how does ejbCreate fit in the following steps?

Thanks.

[Dilip Gamage]

pls see the page ejb 2.0 spec According to that it will never happen.
I think it may be mistake .. or another synario. If you going to get the exam your logic should be according to spec.

Please refer page 80 -81 in EJB 2.0 spec

[Leena Diwan]

Originally posted by Shiang Wang:
EJBObject already exists in the container before setSessionContext() is called, why can't I call getEJBObject() on SessionContext in setSessionContext?

No. It does not.

The sequence is-
1. Instance creation
2. call to setSessionContext
3. call to ejbCreate (wherein the things specified by you happen)

Regards,
Leena

[Shiang Wang]

If you look at page 83 on the spec or page 192 on HFEJB, you will see a new EJBObject is created before setSessionContext() is called. My guess to my own question is that the EJBObject is not associated with SessionContext in setSessionContext(). Somewhere between ejbCreate() and setSessionContext(), EJBObject becomes available to SessionContext.

Shiang

[Rohit Bhagwat]

I also have the same doubt. When I refered to specs page 81 it says
"Invoking the getEJBObject and getEJBLocalObject methods is disallowed in the session bean methods in which there is no session object identity established for the instance."

I have not understood the meaning of there is no session object identity established for the instance.. What does this mean ?

As per my understanding, for stateful session bean, here's the sequence, after calling create method.
1.EJBObject is created
2.SessionContext object is created
3.Bean constructor runs
4.setSessionContext executes
5.ejbCreate() executes.

From these inference, if I am correct, SessionContext object is associated with the EJBObject and the bean once the setSessionContext method returns. And that might be the reason why we cant call getEJBObject method from setSessionContext method. Because the EJBObject is still not associated with the bean. Please correct me if I am wrong.

Waiting for your reply

Thanks and Regards
Rohit.

[Rajan Murugan]

When it is stateful session bean the sesssion is client specific.In ejbCreate only you can retrieve the client specific details sent (if any) as arguments and can associate to identify a client uniquely.so naturally a ejbObject is associated to that partifular client only in ejbCreate.that should be the way it should go.

----------------
[ October 08, 2006: Message edited by: Rajan Murugan ]

[Rohit Bhagwat]

Well Rajan, your suggestions sounds great and easy to remember..But can you just give me your comments on the following statement ?

We know that the creation of stateless session bean is not tied to any client, meaning, it can happen anytime when the container desires. Also, when the client invokes the create method on the remote home's stub, only then an instance of remote EJBObject's instance is returned back to the client. Again. this does not have any binding to the creation of the bean or the session context.

Now, my question is, if these two scenarios mentioned above are isolated events, then how is it possible to get the reference of EJBObject's stub through the session context instance, inside the ejbCreate method, during the invocation of which we may not have a EJBObject at all.


Thanks and Regards
Rohit.

[ October 10, 2006: Message edited by: Rohit Bhagwat ]
[ October 10, 2006: Message edited by: Rohit Bhagwat ]

[Rajan Murugan]

There can be multiple scenarios one may foresee.Assuming the spec is true as for as the table (page 90) and the oids (page 92) are concerned then no logical explanation exists.The reason being as quoted on page 90 is...

The reasons for disallowing operations in Table 3:
Invoking the getEJBObject and getEJBLocalObject methods is disallowed in the session bean methods in which there is no session object identity associated with the instance

Invoking the getEJBObject and getEJBHome methods is disallowed if the session bean does not define a remote client view

if these statements are what they imply and the table says it is allowed in ejbCreate both in cmt and bmt bean.what does it say.one possible explanation that possible is ejbCreate gets called not after setSessionContext but after EJBObject creation.Then you have the session object and the client identity too.

Strangely the authors of HFEJB too have left out ejbCreate in the explanation .Was it delibrate ? or is it that both bert and kathy are enjoying from their pools !!! breaking

or is it the spec implementors left out unknowingly make us wonder :roll:

[Rohit Bhagwat]

Originally posted by Rajan Murugan:
There can be multiple scenarios one may foresee.Assuming the spec is true as for as the table (page 90) and the oids (page 92) are concerned then no logical explanation exists.The reason being as quoted on page 90 is...



if these statements are what they imply and the table says it is allowed in ejbCreate both in cmt and bmt bean.what does it say.one possible explanation that possible is ejbCreate gets called not after setSessionContext but after EJBObject creation.Then you have the session object and the client identity too.

Well but if you refer to figure 12 OID for creation of a STATELESS session object i.e article 7.9.1 from specs then you will see that when client calls create method on home interface then only the EJBObject is getting created, as understood from the diagram. And if we refer to figure 15 from specs i.e Adding instance to pool then you will notice that ejbCreate method is called at the mercy of Container.And now I am totally confused !!

[Rajan Murugan]

Hi,
Think for a while assuming you are a container provider as to how you will go about implementing the spec(assuming the spec is fully "true" diagrammatically and table-wise).
I only put forward one scenario to explain.
As a container provider you can do what I suggested to make the client feel as if he is the boss and his create resulted in ejbCreate getting called.

Even though that is not what the spec wants to mean.ejbCreate gets called after setSesssionContext().

Can you or anyone else think of scenarios where as a container provider I can make this requirement come true !!!

Are Kathy and Bert still in their pools !!!

Please join us for awhile...

[Rohit Bhagwat]

Hello friends, Rajan

Please correct me if I am wrong.

EJBObject is created just before container calls ejbCreate method when client calls create on the bean which can either be stateless or statefull.
So in either case you can get EJBObject using SessionContext object in ejbCreate method which is what the table says for both stateless and statefull beans in specs.

Rajan this is what you were trying to explain me right ?

But this statement violates the information shown in Fig 12 article 7.9.1 in the EJB 2.0 specs which says EJBObject is created only when client calls create method.

Thanks and Regards
Rohit.
[ October 14, 2006: Message edited by: Rohit Bhagwat ]

[Rajan Murugan]

Originally posted by Rohit Bhagwat:
Hello friends, Rajan

Please correct me if I am wrong.

EJBObject is created just before container calls ejbCreate method when client calls create on the bean which can either be stateless or statefull.
So in either case you can get EJBObject using SessionContext object in ejbCreate method which is what the table says for both stateless and statefull beans in specs.

Rajan this is what you were trying to explain me right ?

But this statement violates the information shown in Fig 12 article 7.9.1 in the EJB 2.0 specs which says EJBObject is created only when client calls create method.

Thanks and Regards
Rohit.

[ October 14, 2006: Message edited by: Rohit Bhagwat ]

EJBObject is created just before container calls ejbCreate method when client calls create on the bean only for stateful.
You can get EJBObject using SessionContext object in ejbCreate method for stateful and stateless.True.For stateful there is no conflict.Because bean instance is created when create is issued as per figure 6 for stateful.

Our discussion is for stateless where we see conflict.Since the spec must have been reviewed by umpteen number people internally and publicly I am not questioning the spec.I am assuming it is "true" totally.

The question is how if the bean creation in stateless happens at a totally different point of time can reveal its ejbObject in ejbCreate ? Since ejbCreate gets called just after bean creation(constructor + setSessonContext + ejbCreate) as shown in figure 15 same chapter 7.

Since ejbObject need to be present so getEJBObject can return a value,how can we precreate the beans?

Then only after ejbObject is created due to create call by client can we have ejbObject and that may result in the bean instantiating getting kicked off.

Is there some other way? what will you do if you expect 100000 clients per bean for 10 different beans.And we decide to create rather precreate 100 beans per bean type in the pool.Whether we will precreate or wait for 100 create calls from different clients so we can create the beans?(which later will end up in the bean pool after servicing the client) so we end up with 100 bean instances.

Well this could be one way of implementing the spec as it is.

Any other way?

:roll:

[Rajan Murugan]

Hi Rohit,
Were you able to find anything new?I found something.Well, refer to page number 101 (HFEJB) "architectural overiview" (for stateless) First para- it says --->

"The home gives the client a stub to an existing EJBObject but does not associate a bean with this EJBObject !"

And,in the bottom page point No 4. it says

An EJBObject is created for this client.

If point 4 implies EJBObject creation or usage of preexisting EJBObject then the whole picture falls in place.

It seems the spec is not a hard and fast rule."do or die" rule.it allows for flexibility.

A question arises,to what degree? Which is a "do or die" and which is not?

Anyone has any answers please ???
[ October 19, 2006: Message edited by: Rajan Murugan ]

[Rohit Bhagwat]

Hi Rajan,

Well sorry for the late reply. Actually I am new to EJB and hence cant comment more confidently. Anyways..

When I deployed a stateless session bean in Sun's Reference Implementation server I did the following tasks
1. Put System.out.println() in each and every callback method in the bean.
2. Created a client which just calls the create method and no business method.
3. I was amazed when I saw no output on the screen.

Then I called a business method after create(). Here I saw the constructor getting called, then setSessionContext() and then ejbCreate().

So from these two inferences what I can understand is when you call create then either the reference to newly created EJBObject is returned or an existing EJBObject which the server made at earlier point of time is returned. Now when I call the business method at that time the ejbCreate is getting called so now I obviously have a reference to EJBObject and hence I can call getEJBObject() method on SessionContext object in ejbCreate().

Thanks and Regards
Rohit.

[Rajan Murugan]

Great.So,atleast one scenario that we analyzed is right.Wondurful.