• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

SLSB, ejbCreate() and access to EJBObject

 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
In Stateless Session Bean, Actual bean creation and ejbCreate() invocation will happen unrelated to the actualt client invocation of create(). For example bean creation and ejbCreate() is invoked to create a bean and add it to pool. Later client may come and call create() on Home which will then create the EJBObject. tHis is how it is define in HFEJB book. In that case how can ejbCreate() have access to EJBObject? EJBObject wont be created while the ejbCreate() is being executed. PLease explain how this is possible.
Thanks,
Phani
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In that case how can ejbCreate() have access to EJBObject? EJBObject wont be created while the ejbCreate() is being executed. PLease explain how this is possible.


I am not reading HF book Here is what i think.
I think bean instance and EBJObject are two separate objects. ejbCreate is called on the bean instance. The EJBObject represents the the class implementing the remote interface. When container instantiate a bean instance and call setSessionContext and finally call ebjCreate. The bean instance is already established. ejb spec simply requies container to make the EBJObject available to the bean instance at this point.
 
Phanindra Nayani
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
EJBObject is available at that point means, EJBObject instance which is representing the bean. It does not mean EJBObject class type which is allways available. I think you assumption may not be correct. Anyway thanks for trying to help me.
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The spec OID diagrams tend to be a bit clearer than HFE on issues like this, but SLSB is the significant the counter-example. The vary nature of a SLSB means you have to interpret some interface methods in a slightly more subtle fashion:
In SFSB, SessionContext.getEJBObject gets you *the* EJBObject, i.e. the bean instance and the client both have to be accessing the same EJBObject because to service any requests correctly they both need access to the same conversational state.
In SLSB, SessionContext.getEJBObject gets you *an* EJBObject, i.e. the bean instance and the client don't require access to the same EJBObject - to the container all bean instances and hence all EJBObjects are equally suitable for servicing requests.
[ February 23, 2004: Message edited by: Reid M. Pinchback ]
 
Jack Zhou
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I do mean the instance of the type EBJObject to available.
Here what is from java doc

I believe an instance of EJBObject is an instance of a class that is created by container and implements the component interface provided by bean provider. This instance implements Remote.
A bean instance is usually an instance of the bean class that is usually not a Remote.
As the java doc says, the getEJBObject "Obtain a reference to the EJB object that is currently associated with the instance". It is client view of the "bean instance". It is the the proxy of the "bean instance" whose existence my be not neccessarily tied with the existence the EJBObject. When client calls create() on the home object, it returns an EJBObject which is a remote. Container need to assoicate a bean instance so that the client's subsequence call to this EJBObject is delegated to the bean instance. Container my create a new bean instance or use one in the pool to complete this assoication.
The ability to obtain a "associated EBJObject reference" should be looked as an evidance of this association not the existence of the bean instance or the remote EJBObject.
Thanks,
 
Phanindra Nayani
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry guys, Im not able to understand your point. Are you saying that there is some arbitary/temporary EJBObject instance associated with the bean when ejbCreate() is being executed?
 
Jack Zhou
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The answer is Yes. But it may not be an arbitary one. I don't think it matters it is temperary or not for stateless sb. When a client calls on a remote interface, you can imagine it is like a RMI call, at the client side the EJBObject is like a stub, at the serverside the EJBObject is like skelleton. But these are one possible implmentation details. As far as EJB spec concerned, EJBObject is the Proxy for client interact with ejb or as ejb spec put it "client view" of the ejb.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think that Jack is saying that the javadoc suggests that SessionContext.getEJBObject returns you the same object that a remote client is accessing. In general the spec materials are written from the standpoint of SFSB, with a few "oh and by the way here is requirement in the case of a SLSB" caveats thrown in. I suspect that the javadoc reflects this tendency to discuss session beans from the standpoint of SFSB.
I'm saying that for a SLSB that it would be wierd to require such a correspondence when you are in ejbCreate, and the spec guarantees you can get an EJBObject while within ejbCreate on a SLSB. Besides, I don't see why it is computationally necessary for it to be the same object in the case of a SLSB. Remember that EJBObject.isIdentical is *always* true for SLSB. All session beans are considered equivalent to the container for a SLSB. Given that a remote client is, well, remote, it isn't like you'd *ever* be in a position to compare the reference you have in your bean to the reference that is used as the server-side skeleton to service client method calls. I suspect that the container is perfectly free to create any old EJBObject for the bean to use, but *only* in the case of SLSB. Basically you are saying "gee, I have a client, and the client is me".
[ March 03, 2004: Message edited by: Reid M. Pinchback ]
 
Phanindra Nayani
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thankyou Guys !!!
 
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This question already appeared once and the author kathy's reply is:
https://coderanch.com/t/158485/java-EJB-SCBCD/certification/beanness-stateless-session-bean
 
Popeye has his spinach. I have this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic