HF questions and others - round 1

[Keith Rosenfield]

Hi All:
Please answer as many of following as you can
1) What advantage, if any, is there to setting a transient variable to null in ejbPassivate() since there is no guarantee that it will be assigned a default value after activation? It seems unecessary to me since you will need to set the values appropriately in ejbActivate() regardless.
2) The diagram on page 208 indicates ejbRemove() or timeout will cause a bean to go from the method ready state to the does not exist state and that these events are both mutually exclusive. Isn't it the case that remove() or timeout will cause this transition and that ejbRemove() will result in both cases?
3) I noticed that AdviceStatfulClient code on page 219 includes the line advisor.remove() whereas the AdiveClient on page 57 does not. Why doesn't it? I thought that a client should call remove on stateFUL as well as stateLESS session beans.
4) On page 225 point 1, shouldn't the container call ejbCreate() after calling setSessionContext() since on page 227, ejbCreate() is shown as the last step of bean creation?
5) On page 228, the table shows that a stateless session bean can get a reference to an ejb object from ejbCreate(). I don't understand how. Isn't ejbCreate() called when the bean is brought into existence and there is no ejb object associated with it at that time?
6) To what extent do we need to know BMT for the exam? Do we need to know what access a BMT bean has in all of its methods? For example, do we need to know the BMT side of the table on page 90 of the spec?
7) What are the semantics of a stateLESS session bean removal? I imagine that the ejbObject is "killed" and the bean is put back into the pool. Is there more to it than that?
Thanks for your input.

[Anthony Watson]

Originally posted by Keith Rosenfield:
I thought that a client should call remove on stateFUL as well as stateLESS session beans.QB]

The client does not NEEDto call remove for stateless session beans because stateless session beans are only tied to a client during a business method. The container is responsible for maintaining its pool of stateless instances and that has nothing to do with what the client wants. The client CAN call remove for a stateless bean (won't cause an error), but the container will just ignore that call and say, "well, if you don't want that bean instance, I know that some other client might, so I'm not going to remove anything."

[Keith Rosenfield]

Hi Anthony,
Doesn't calling remove on a stateless session bean "kill" the ejbObject?
One question answered. Six more to go.
If you know an answer, please contribute.
Thanks.

[Vishwa Kumba]

Originally posted by Keith Rosenfield:

5) On page 228, the table shows that a stateless session bean can get a reference to an ejb object from ejbCreate(). I don't understand how. Isn't ejbCreate() called when the bean is brought into existence and there is no ejb object associated with it at that time?

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

[Vishwa Kumba]

Originally posted by Keith Rosenfield:

6) To what extent do we need to know BMT for the exam? Do we need to know what access a BMT bean has in all of its methods? For example, do we need to know the BMT side of the table on page 90 of the spec?

Unlike CMT, I don't think there are any questions asked in detail about BMT or BMP in the exam. We can ignore the BMT colum in the Operations table in the Spec.
But it's required to know when setRollbackOnly, getRollbackOnly, getUserTransaction and getStatus methods can safely be used.
For example :
1. Which of the above methods are allowed in BMT and which are not.
2. And if you use the not-allowed methods what exception would you get.....
3. What exception would you get if you try to open a nested transaction
in a BMT session bean etc...
The foll. link might be useful.....One of the Ranchers, Ashik had composed
short notes from Kathy's posts earlier.
http://www.ourbangla.com/scbcdbetaexam.doc
There may be a few errors in the sample mock questions, you can ignore them. But what is important is Kathy's Tips, of what to expect and not what to expect in the exam. I found it quite useful for the exam.

[Keith Rosenfield]

Hey Vish:
Thanks for your input.
3 questions down, 4 to go.
Please contribute if you have an answer.
Thanks

[Venkatesh Kumar]

Originally Posted By Keith
"Doesn't calling remove on a stateless session bean "kill" the ejbObject?"
Yes,the EJB Object is destroyed but the stateless session bean goes back to the pool waiting for a client to call a business method.

[Keith Rosenfield]

Hey Venkatesh,
It occured to me that calling remove on a stateless session bean doesn't cause it to go back to the pool. It goes back to the pool when it has finished executing a business method. I suppose the only thing that happens is that the ejbObject is destroyed. Can anyone confirm this?
If you know the answer to any of the unanswered questions, please contribute.
Thanks for your input.

[Philippe Maquet]

Hi Keith,
1) No real advantage IMO.
2) The answer is on p.208. But notice that both events (a client calls remove() / timeout when active) are *NOT* mutually exclusive.
3) The call to remove() is simply missing on p.57 IMO. You're right, with both types of session beans, calling remove() just means "I'm done with that bean.".
4) Yes, you're right.
5) Nothing to add to the link provided by Vish.
6) Nothing to add to what Vish wrote above.
7) Yes, when a client calls remove(), the stateless session bean stays in the pool. But I don't think that the EJBObject is actually "killed" (similar reasoning as what Kathy wrote in this thread.
Best,
Phil.

[Roger Chung-Wee]

Am I correct in thinking that we should not care what happens to the EJBObject after a call to remove() as this is an implementation detail; rather, we need to know that remove() should be called as soon as possible for efficiency reasons, ie so that the container can discard the stateful session bean or entity bean.