Win a copy of AWS Security this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

create method in home interface (stateless session bean)

 
Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ...
 
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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!
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
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!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic