2 Interesting Mock Questions

[Alec Lee]

TRUE or FALSE for these 2 statements:
1) Only stateful session beans can be passivated.
2) session bean class can support overloaded constructors.
=====================
I think (1) should be false while (2) should be true, although the answer says (1) is true (2) is false.
Both questions use the word 'CAN' meaning they are true if the specification does not explicitly prohibit them.
Well, I search thru the specification and cant really find any comment about stateless bean cannot be passivated. Recall that their bean class
need to give empty implementation of ejbActivate/ejbPassivate anyway. It is meaningless, but possible that the container can call these 2 methods and serialize the bean instance to hdd.
Also, EJB spec section 7.10.2 says a public constructor with no argument must be provided to sbean class. But it does not mention it cannot provide other constructors taking some arguments (although would not be called anyway).
Am I right?

[Micheal Lau]

i just have the feeling that sometimes the mock questions are little bit of confusing:
just like your question 1: "only statful session bean can be passivated?"
first what does the meaning of passivate? calling "ejbPassivate()"?
how about the entity bean?
so i guees the answer is false ...

[Vishwa Kumba]

My answers would be.
1. true
2. false
What use would it be if you have a default constructor with no args
as well as other constructors for a bean class?
What use would it be if you have some code in ejbPassivate() and ejbActivate() in the SLSB class, when these methods would never be called.
According to the bean law, SLSB does not support ejbActivate and ejbPassivate().....and constructors cannot be overloaded for any of the bean classes.
EJB2.0 Spec, p:88, Sec 7.8
"A container only needs to retain the number of instances required to service the current client load. Due
to client "think time", this number is typically much smaller than the number of active clients. Passivation
is not needed for stateless sessions. The container creates another stateless session bean instance if
one is needed to handle an increase in client work load. If a stateless session bean is not needed to handle
the current client work load, the container can destroy it.
Because stateless session beans minimize the resources needed to support a large population of clients,
depending on the implementation of the container, applications that use stateless session beans may
scale somewhat better than those using stateful session beans."

[Vishwa Kumba]

Originally posted by qwejst qwejst:
It is meaningless, but possible that the container can call these 2 methods and serialize the bean instance to hdd.

Some Vendors may do it or may not do it for SLSB, but the EJB spec does not say so. I think ejbActivation and ejbPassivation has been introduced to improve the scalability of SFSB....But from a resource point of view, due to the differnces in their life cyle and use, SLSB and MDB are much more scalable than SFSB. So I do not see any reason why vendors could think of serializing SLSB to improve performance.....
It is just that SUN did not want to have a separate interface for SLSB and SFSB......they came out with only one interface," Session interface". Of course, it was their design strategy

[Dilli raj]

As far as question 1 is concerned. The answer is TRUE. i.e. for stateless session bean is concerned the instance is associated with the client only for a single method call.once the method call is completed the bean instance returns to the pool. Thus there is no need for passivation. and similarly the bean instance is taken out of the pool only when the client invokes a business method. and once the method execution is completed the instance goes back to the pool making itself available for other clients request.
As far as question 2 is concerned. The answer is FALSE. refer to specification (7.10.2) page no 95 which says that the session bean must have a public constructor which takes no argument.

Dilli
[ February 06, 2004: Message edited by: Dilli raj ]

[Micheal Lau]

for the question 2:
the word used here is "can support" not "can have"
so the answer is false

[Todor Mollov]

2) session bean class can support overloaded constructors.

from spec. p95 7.10.2
The class must have a public constructor that takes no parameters. The Container uses this
constructor to create instances of the session bean class.

So if I'm syco enough i could have:
public MyBean(){}
public MyBean(String name){}
and my bean will compile and deploy successfully.
The answer is TRUE !

[Micheal Lau]

"can support" -- i think it means the container will/can use the overloaded constructor
of course, if the question is "session bean CAN HAVE overloaded constructor" .. the answer is true