Byron's SCEA Preparation Exam: Question #2

[Byron Estes]

I am currently preparing for the SCEA. In order to prepare myself and help others, I will periodically post questions for discussion.
I will post the question and the answer with an explanation separately.
I�d like to get feedback on the correctness of my answer/explanation and constructive criticism to make the question better.
I�ll take your feedback and update the question/answer and aggregate them into an exam, which I will later share with the group.
Byron Estes

Question #2
If a client calls the remove() method on the Home interface of a stateless session bean, the following is TRUE?
a)The session bean instance is always destroyed
b)The session bean instance cannot be assigned to another client.
c)The session bean instance may be destroyed or returned to the pool.
d)The session bean instance may be or may not be destroyed.
e)The session bean is never destroyed, just returned to the pool.
f)The session bean is passivated.

[Byron Estes]

The answer is �D�. This is completely at the discretion of the container which may choose to physically destroy the instance or not.
Answer �A� is incorrect because the container may opt not to destroy it.
Answer �B� is incorrect. All Stateless session beans are equivalent and maintain no conversational state. They can be used by any client at any time.
Answer �C� is incorrect. This is a bit of a trick question. The instance may be destroyed, but the instance never really leaves the pool, so it can�t really be returned to it. In reality, any client can call any method on any EJB Object in the method ready pool.
Answer �E� is incorrect. The session instance could be destroyed. Also see answer �C� for explanation regarding �instance pools and stateless session beans�.
Answer �F� stateless session beans don�t have conversational state and are not passivated. This only applies to stateful session beans, not stateless session beans.

[Craig Jackson]

I agree with most of what your explanation states, but I believe the answer is (E). Because the stateless session bean does not maintain state, the session bean instance can be freely swapped between EJB objects. Therefore a timeout or remove inovation on a stateless session bean only invalidates the EJB object reference to the client, the bean instance is not destroyed and is free to service other client requests. I think the trick part of the question is "the client calls the remove() method". True, the container can choose to remove bean instances, but the calling of the remove() by the client will not remove the stateless bean instance.
my 2 cents
Craig

[nitin shar]

I think Craig is right.
calling remove() from client on Home interface only invalidates the EjbObject for that client and moves the Bean instance to pool , where it can be used by any other client.Container decides when to remove the bean.

[nitin shar]

Ed Roman says this in life Cycle diagram of stateless Session Bean that Container decides to move the Bean from ready pooled state to does not Exsist state when it thinks it does not need so many instances of the Bean.

Nitin

[Byron Estes]

Guys,
Thanks alot for the feedback! This is exactly the kind of discussion I wanted to obtain. To get different pespectives and interpretations of the wording so it can be refined.
I agree with all of you that the Container is in full control of when the bean is destroyed.
Looking at the answers again I can see why someone might confidently select "E" as the correct answer.
...but "I think" using the absolute word NEVER in "E" makes it incorrect because the CONTAINER IS IN CONTROL. The remove as implemented by the container in a given situation/environment may choose to destroy the bean instead of returning it to the pool.
However, I now see that this may be too fine a line to draw and the answers should be reworded slightly...
d) The session bean instance may be returned to the pool or destroyed.
e) The session bean is never destroyed, just returned to the pool.
Thanks again. I hope you'll continue to help refine these questions!

[Emil Kirschner]

Originally posted by Byron Estes:
The answer is �D�. This is completely at the discretion of the container which may choose to physically destroy the instance or not.
Answer �A� is incorrect because the container may opt not to destroy it.
Answer �B� is incorrect. All Stateless session beans are equivalent and maintain no conversational state. They can be used by any client at any time.
Answer �C� is incorrect. This is a bit of a trick question. The instance may be destroyed, but the instance never really leaves the pool, so it can�t really be returned to it. In reality, any client can call any method on any EJB Object in the method ready pool.
Answer �E� is incorrect. The session instance could be destroyed. Also see answer �C� for explanation regarding �instance pools and stateless session beans�.
Answer �F� stateless session beans don�t have conversational state and are not passivated. This only applies to stateful session beans, not stateless session beans.

Hey,
C in very tricky indeed.
Assume you have a reference to a bean and then you release it. In some cases depending on the management algorithm, when you release the bean some condition may be met which would trigger the container to re-dimension the pool.
ex: you configure your pool to hold min 20, max 50 instances, with a trashhold of 5/10. this means that if you release a reference and there already are 9 free, 10 will become free and the container will reduce the pool size by 5 - means it will let the garbage collector remove 5 instances - have no ideea which ones.
now you can say that the reference is always released to the pool and the pool will shrink a few cycles later or you can say that the instance to which you hold a reference will be destroyed if some internal trashhold level is reached. Fact is, you have absolutely no ideea, since this is not written in the spex. each container provider can do this as they see fit.
all this given, hmmm, I think it's safe to say that the bean to which you hold the reference will either be returned to the pool or be destroyed depending on the pool's internal state at the moment when you release the reference (that is, when you call remove() ).
so in my opinion, C is actually a good answer.
cheers,
e.

[Byron Estes]

Emil,
I appreciate the time you took explaining why you feel that "C" is a correct answer.
But...
Ponder this for a moment. Unlike stateful session beans or entity beans which are trully assigned to a client for some period of time. Stateless session beans because they have no state and are therefore considered to functionally equivalent don't really get assigned out of the pool. The container using the request interceptor mearly delegates the method call to to an available bean and returns.
Because it's never assigned, in my mind it never leaves the pool. It just performs the method. The next call from the client may go to the same stateless session bean or a different stateless session bean. It doesn't matter because they have no "identity or state".
Thoughts? Differing understandings/opinions?
Regards,

[Craig Jackson]

...but "I think" using the absolute word NEVER in "E" makes it incorrect because the CONTAINER IS IN CONTROL. The remove as implemented by the container in a given situation/environment may choose to destroy the bean instead of returning it to the pool.

I agree totally. Because of the word "never" I would have eliminated option (E) almost immediately. The word "never" and "always" are usually keys when a question needs to be eliminated/choosen. If it had said "is not destroyed", I would have jumped all over it. But I believe we should choose the answer within the context of the question. As you stated above the " CONTAINER IS IN CONTROL" not the client. So the client invocation of the EJBHome.remove() method only invalidates the EJBObject reference to the client. When the container no longer needs the instance(usually when the container wants to reduce the number of instances in the method-ready pool), the container invokes ejbRemove() on it. This ends the life of the stateless session bean instance.
You can also flip the question and ask what will happen when a client calls the create() method on a stateless session bean.
what do you think.
cj

[Emil Kirschner]

Originally posted by Byron Estes:
Emil,
I appreciate the time you took explaining why you feel that "C" is a correct answer.
But...
Ponder this for a moment. Unlike stateful session beans or entity beans which are trully assigned to a client for some period of time. Stateless session beans because they have no state and are therefore considered to functionally equivalent don't really get assigned out of the pool. The container using the request interceptor mearly delegates the method call to to an available bean and returns.
Because it's never assigned, in my mind it never leaves the pool. It just performs the method. The next call from the client may go to the same stateless session bean or a different stateless session bean. It doesn't matter because they have no "identity or state".
Thoughts? Differing understandings/opinions?
Regards,

Byron,
you're right, the scenario you describes is perfectly possible and would be a very good implementation of the specs. However, the container provider is not forced to do it this way. The specs say "...the container MAY delegate requests from the same client within the same transaction to different instances and MAY interleave requests from different transactions to the same instance...". It may, it doesn't have to. This means the container implementor is free to do whatever he wants.
In your case, the object is still taken out of the pool, it just happens within each invocation. Your local proxy sends the request to the container, the container checks the object out of the pool, calls the method, releases the object back to the pool. this could be very efficient if the bean is called once per transaction and you have allot of transactions going on.
I agree that the implementation you described may be most efficient one.
There are situations, however, when I would like to keep instance out of the pool during the entire transaction. This may be if methods of a bean are called multiple times during the same transaction. obtaining / releasing the object each time can be costly, cos operating on a pool usually implies locking.
I have no ideea how different containers implement the specs. I guess most would do it as you described. I'll have a look at the JBoss sources, maybe I'll manage to figure it out.
Also the specs say: "the client may call create() and remove() WITHOUT NECESSARILY creating or removing instances". But it may. We cannot generalize.
So if you call remove, generally speaking, you cannot predict what happens. You may for a specific container, but not for all of them.
Does anyone have more info on how all this is implemented?
cheers,
e.

[Byron Estes]

I'm with you CJ and I think the ideas of a similar question related to the create() makes sense.
Regards,

[SPAD]

"C" is the answer - read Emil's response :-)

[Byron Estes]

SPAD,
I did read it, but I just don't agree with it.
My point is that a stateless session bean...
NEVER RETURNS TO THE METHOD READY POOL, BECAUSE IT NEVER LEAVES IT.
There's no need to leave the pool, because there is no assignment. Each one is equivalent, there should no variation in state, so any instance can service any client, thereby negating the need (...and the overhead) of assignment.
Here's a direct quote from the EJB 1.1 Specification...
"There is no fixed mapping between clients and stateless instances. The container simply delegates a client's work to any available instance that is method ready."
If it's not in a method ready state, the only other state a stateless session bean can be in is
"Does Not Exist"
Respectfully,

[SPAD]

----------------------------------
There's no need to leave the pool, because there is no assignment. Each one is equivalent, there should no variation in state, so any instance can service any client, thereby negating the need (...and the overhead) of assignment.
----------------------------------
Byran,
In that case there is no need to even maintain a pool of these beans a single instance can serve request on behalf of all the clients ???
IMHO this is one of those no-right-no-wrong question. This behavior is defined in the EJB specs in a flexible (implementation POV) fashion like many others. Here is a quote from Monson's book:
Page#239 /Second edition
"Stateless bean instances enter the method-ready-pool as the container needs them. When the EJB server is first started, it will *probably* create a number of stateless beans and eter them in Method-ready-pool (The actual behavior of the server depends on the implementation). When the number of stateless instances servicing the client requests is insufficient more can be created and added to the pool".
Now there has to be a maximum and that is the reason I supported the idea of removal or "Does not Exist" state.
-------- ----------------
Regarding the Assignment
-------------------------
The Bean when servicing a request from one client is unavailable for use by any other client i.e., it is assigned to that client & there is a good reason why it should be.
Monson's book again Page# 240 second edition -
" When a client invokes a busines method on an EJB object , the method call is delegated to any available instance. While the instance is exuting the request, its is unavailable for use by otrher EJBobjects."
----
When the bean is removed
------
Monson Page# 241 Secon ed
"Bean instances leave the Method-ready-pool for the does not exist state when server no longer needs the instances. This occurs when the server decides to reduce the total size of the pool..."
Regards,
SPADer
[ July 25, 2002: Message edited by: SPAD ]
[ July 25, 2002: Message edited by: SPAD ]

[Byron Estes]

I have the book you referenced and read the sections that contained them in their entirety, not just the lines you chose.
Much is as always in these case left up to the discretion of the containers as was evident in my quote from the EJB 1.1 Specification.
Hanson talks about an instance being dedicated to a single EJB Object for the duration of a single method call and that during that single method call (because EJB is not multithreaded) is unavailable to be used by other until that call is complete.
He further goes on to state (...and this is where I can begin to see your point) that
"Although vendors can choose different strategies to support stateless session beans, it's likely that vendors will use an instance-swapping strategy similar to that used for entity beans. However, the swap is very brief, lasting only as long as the business method needs to execute."
He even mentioned in a footnote that the container may decide to create and destroy instances with each method invocation. Yuck!
I think you're right the question needs a little rewriting..
What if we rewrite the questio/answer as follows:
If a client calls the remove() method on the Home interface of a stateless session bean, the following is TRUE?
a) The session bean instance is always destroyed
b) The session bean instance cannot be assigned to another client.
c) The session bean is never destroyed, just returned to the pool.
d) The impact to the session bean is not defined in the EJB specification.
e) The session bean is passivated.
f) It depends on your EJB container and it's implementation of the specification.
Now the correct answer would be: d and f.
Better?
Friendly FYI: SPAD the sherrifs/bartenders will probably ask you to change your user name because it doesn't conform to thier policies, you may want to beat them to the punch.
Regards,

[SPAD]

Byran,
Thanks for the FYI - I will wait for the Punch
Anyway how about adding the following choices:
(i)May be removed from memory that is "Does not Exist" (true)
(ii) May be put back to the pool (true)
(iii) Always put back to the pool (false)
(iv)Always removed
(v) Converted to a Statefull Session Bean
Cheers,
SPAD