This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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?
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 ...
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."
Joined: Aug 27, 2003
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
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 ]
Joined: Feb 02, 2004
for the question 2: the word used here is "can support" not "can have" so the answer is false