What does remove() means for a stateless session bean?

[X. Li]

I used example "Advice" from HF EJB to test remove() method for stateless session bean. I called remove(), then tried to call getTheMessage(). It's still working! That looks like remove() doesn't make any sense for a stateless session bean. Is this true?

Here are codes:
------------------------------------------------------
AdviceHome home=(AdviceHome) PortableRemoteObject.narrow(o,AdviceHome.class);

Advice advisor = home.create();
System.out.println("From Advisor: "+advisor.getTheMessage() );

//remove the bean
Handle handle=advisor.getHandle();
home.remove(handle);

//after remove
System.out.println("From Advisor (after Removed): "+advisor.getTheMessage() );

------------------------------------------------------

[VP Jain]

Hi,

Yeap remove() doesn't make any sense for a stateless session bean.

If u look into the life cyle of stateless session bean, the creation
of the stateless session bean is taken care by the container, unlike the
stateful session bean.So remove() in stateless session bean doesn't make
any sense.

[X. Li]

Thank you, Vijayakeerthy.
I did look into the life circle of a stateless session bean. Just wonder why it's not declared in HF EJB (I only read a half of the book so far).

Li

[Sandesh Tathare]

Well it's really funny. It actually worked like what you have said. I was expecting java.rmi.NoSuchObjectException.

I also tried removing EJBObject using EJBObject.remove() method, but there's no change in result. The business method runs fine.

I referred to Object Interaction diagram under Section 7.9.3 Client-invoked remove() of EJB specification, but there's no clarity imposed by Specification whether the EJBObject is killed by Container or not. In case of Stateful Session Bean, Container kills bean and EJB Object as per diagram on page 209 of HF EJB.

I think as below:
In case of Stateless Session Bean EJB Container Provider has freedom to provide implementation on what to do with EJBObject after receiving remove call from EJBObject Stub.
As we all are aware, Container provider is not required to kill bean instance, as it returns to pool after completion of business method. So Container Provider is least bothered about providing any handling when remove call is received from stub of Stateless Session Bean. Possibly Container provider has forgot that he/she is required to kill EJB Object reference. This could simple be a BUG or there could be totally different story to it.

Please refer to page 98 of HF EJB. It states as:

Each client gets his own EJBObject reference and his own bean. The client never shares a bean with another client, although the meaning of "shares" depends on whether the bean is stateful or stateless.

So I am arriving at a conclusion as:
Clients share EJBObject in case of Stateless Session Bean.

Please correct me if I am wrong.

[X. Li]

Hi Sandesh,

In P.103 of HF EJB, it clearly says: "Clients don't share EJBObjects, but...". I agree with it. My understanding is when you call remove() of a stateless bean, you are removing the EJBObject itself, not bean. Bean is supposed to be returned to the pool by container. However, it seems not, looks like this stateless bean is following the life of the client once it's created, except it doesn't keep "conversational state". If so, where is the "Scalability"? Is this a bug? I don't know, I am new to EJB.

[Sandesh Tathare]

Thanks for referring me to page 103 of HF EJB.

But then this triggers thought that either this is a bug or possibly Container is doing some things which we (Bean Providers) don't know. Possibly container is reusing EJB Object from 1 client to some other, once client calls remove. But then at least client 1's further business requests should lead to Exception. This is all messed up now.

:roll:

[Arun Krishnamoorthy]

Refer to this response from Kathy Sierra on a differnet question:

[Arun Krishnamoorthy]

Sorry... I sent out an incomplete response.

Refer to this response from Kathy:

https://coderanch.com/t/158485/java-EJB-SCBCD/certification/beanness-stateless-session-bean

Focus on this statement:

And remember, this is not a problem because all stateless beans of a certain type can use ANY EJBObject for that bean type, since every stateless bean of a specific type is the same as any other, and so it is the same with the EJBObject references for beans of that type.

So, the container has the option of preserving that EJBObject type if it deems appropriate and hence, would be an implementation detail. Note that its possible for the container vendor to have only ONE instance of EJBObject for a stateless session bean (not necessarily one for each client making a business method call).

[X. Li]

Thanks Arun.
Kathy only mentioned ejbCreate() method there. Here I got another question:
In P.228 of HF EJB, it says:" (in ejbCreate(), ejbRemove()),Use your SessionContext to do
1. get a reference to your home;
2. get a reference to your EJB object;
...."

However, from my test of stateless Advice, the ejbRemove() is never called by container, even if client called remove() method. That means anything you did in ejbRemove() will not make any sense. So, the above statement seems applicable to ejbCreate() only. Is this correct ?

regard.

[Arun Krishnamoorthy]

I want to clarify that although the original discussion is pertaining to ejbCreate(), the quote I added from that discussion is applicable to any method call using the component interface's stub on any client.

With that said, ejbRemove() gets called ONLY by the container for stateless session beans. It is not tied to the remove() call you make from the client through a home or component interface. The container calls ejbRemove() on its own prerogative...for instance, if a stateless session bean pool size is configured at 5 and there are 8 clients trying to make a business method call simultaneously. The container would make three additional stateless bean instances of that type (remember, session beans are non-reentrant) to enable processing of these business method calls. Once the business calls are done and the container is not using these additional three instances for a certain period of time, it would call ejbRemove() on the bean and then destroy the bean.

So, in conclusion, ejbRemove() for a stateless bean does get called only when the container needs to reduce the instance pool size.

[X. Li]

Yes, you are right, ejbRemove() may get called by container, but when? the bean provider never knows. So why allow bean provider to do something in this method? My conclusion for ejbRemove() of a stateless session bean is:
"In ejbRemove(), you should not do anything. Even if you did something in this method, it will never make sense to you."

[Arun Krishnamoorthy]

I am not sure I agree with you...there could be instances where we may need to do something in ejbRemove() for a statless session bean. For example, consider that a stateless session bean needs to communicate with an external legacy system through Sockets from its business methods. Assume there is considerable overhead in attempting to make a socket connection to this external system. So, I would want to get a socket connection only once, use it in my business methods as necessary, and release the connection only when the bean instance no longer exists. You can acquire the socket connection in ejbCreate(). To release the socket connection, you would have to use ejbRemove() so that when the Container removes the bean instance, the socket connection is also released. Of course, if there's a system exception or if the container crashes, ejbRemove() would never get called and we would not release the socket connection [one way to handle this would be to set a timeout on the socket connection].

What do you think?

[X. Li]

From Spec, stateless bean doesn't keep "conversational state". That means: you get socket connection in ejbCreate(), but bean doesn't keep this connection for you when you make another call. Actually, you may get different bean instances in successive calls even if you called one create()from home interface. Therefore, you can't expect container to release that socket (that bean holds the connection may already belong to another client, I don't know). If you need to release it, perhaps you should get socket connection in ejbCreate(), do something, then release the connection immediately in ejbCreate().

Regards.

[Arun Krishnamoorthy]

I think you misunderstood what I said...the stateless session bean is not trying to maintain conversational state in the example I gave you.
Variables in stateless session beans should ONLY contain state which can be used by any client instance and not state which is specifically stored for a specific client instance.

The socket connection in the bean instance remains the same for "ANY" client instance even though it may be used by multiple clients at different times. The purpose of the socket connection may be to send some information to the external system based on "parameters" (local variables) passed to the business method.

If I am still not clear, let me know...