I assume the only valid create method in the hoem interface of the stateless session bean is create(). The method createABC() won't be allowed for stateless session bean. Can anybody explain why? The createABC() method does not take any parameter. This means my bean can be stateless ... Thanks in advance ...
SCJP, SCJD, SCWCD, SCBCD, SCEA, IBM Certified Enterprise Developer, WebSphere Studio V5.0
There are two reasons that I can think of. 1) The container calls ejbCreate() when it creates the bean and puts it in the pool. This is not at the same time that the client calls create(). There is no way for the container to know that it should call ejbCreate<method> instead. Therefore you must provice the ejbCreate() method. The reason that statefull session beans can use create<method> is that the bean is created at the time that the client calls the create<method>. The container would call the corresponding ejbCreate<method>. 2) There is no need for overloaded create methods. The only create method that is necessary is one that takes no parameters.
Originally posted by Edy Yu: The createABC() method does not take any parameter. This means my bean can be stateless...
As you said, SLSB can have only one create method wih no parameter, So there is no any real benefit of having a create method with different suffixes for different bean providers. I guess SUN wanted to keep the name as simple as possible, so "create" They did not want to add more confusion to the naming conventions for the EJB methods!
Originally posted by Edy Yu: I assume the only valid create method in the hoem interface of the stateless session bean is create(). The method createABC() won't be allowed for stateless session bean. Can anybody explain why? The createABC() method does not take any parameter. This means my bean can be stateless ...
How a particular create method on a home interface relates to a corresponding ejbCreate method on the bean implementation differs according to the kind of bean. Basically the reason has to do with the differences in the lifecycle of the two types of session bean. - Stateless session bean Client calls create() really to get a stub. Doesn't directly cause ejbCreate() to be called (container creates a bean instance as needed) - Stateful session bean Client calls a particular createXXX() to create a stub and an instance configured according to the corresponding ejbCreateXXX(). When you have an EJBObject/EJBLocalObject stub for a stateless bean, you don't have a specific session bean instance associated with your stub. The container waits until you ask it to do something and temporarily assigns a bean instance to handle your request. If all instances are equal, there is no point (and no opportunity) for a client-specific way of creating the bean. Thus only one ejbCreate() method. When you have an EJBObject/EJBLocalObject stub for a stateful bean, you get a specific instance assigned to you for as long as you need it, because you'll potentially be changing the state of that bean. The client has the added bonus of being able to tell the container to use a specific ejbCreate() method to initialize the bean the way the client wants. That doesn't hurt any other client - they each had their own opportunity to initialize their own private instance of their stateful session bean.
Reid - SCJP2 (April 2002)
But how did the elephant get like that? What did you do? I think all we can do now is read this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!