Discussions

EJB design: Can EJBObjects (or EJBLocalObject) instances be cached ?

  1. Ejb specification 2.0, final release
    (http://java.sun.com/products/ejb/docs.html) Secion 7.5.6 (Serializing session bean methods - page 76) says that


    "A container serializes calls to each session bean instance... Clients are not allowed to make concurrent calls to a stateful session object. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client, if the client is a remote client, or the javax.ejb.EJBException, if the client is a local client."


    Then it goes on to say that -


    "This restriction does not apply to a state-less session bean because the container routes each request to a different instance of the session bean class."



    My question is -

    Does this mean that it is safe to obtain a stateless session bean reference (by calling ejbCreate on its home) in, lets say the init method of a servlet and store the object reference in a servlet instance variable. Can the instance variable be used in doPost/doGet method of the servlet - knowing that doPost/doGet will be invoked concurrently by many clients.

    The reason I ask this is because, I have never seen this session bean reference caching in any book/tutorial/article. I have always seen clients creating a session bean when required. In some places I have seen caching of the home object through some kind of service locator, but never the EJBObject/EJBLocalObject.

    I have tested the scenario (by using a multi threaded remote client on a multiple cpu machine) for weblogic 8.1 SP3 on Windows 2000 and it appears to work. But is
    it safe to assume that the specification allows me to do this?
  2. Kingshuk,
       The theory sounds interesting but the question here u need to ask is what r u really gaining by caching EJBObject/EJBLocalObject (Remote or Local stubs ).Caching HomeObjects really makes sense because it involves the costly process of making Jndi calls. But caching Remote objects unnecessarily increases complexity w/o giving too much of gain . Also considering the fact that EJB 1.2 and above allows local interfaces creating a stub doesnt even need a remote call for the cached HomeObject stub if that is the argument .Though as far as EJB specs goes I think it does not restrict you from doing this .

    Cheers
    Deb
  3. Thank you Deb for your response. My question was driven not as much by the need to design application that way. I was just curious whether such a thing is possible at all.
    But caching Remote objects unnecessarily increases complexity w/o giving too much of gain
    Disagree on the "unnecessarily increases complexity" bit though. I find it natural (in some cases) and simple to program classes that upon instantiation create all other objects whose services they need. Sometimes lazy instantiation (defer creation) is required but that is driven by the nature of those objects (they may encapsulate shared scarce resource or large data etc..) not by programming style or design practice.
    Also considering the fact that EJB 1.2 and above allows local interfaces creating a stub doesnt even need a remote call for the cached HomeObject stub if that is the argument.

    That was not the argument. But thinking of that, if the web application or ejb client is hosted on a different jvm then the option of using local home objects are not available.


    Incidentally, I realized after posting this that about 2 years back other people have asked similar questions in this forum. I should have done a search before posting.

    In case you are interested in those discussions

    http://www.theserverside.com/discussions/thread.tss?thread_id=11022

    And a good discussion here about the thread safety of the home object itself that everyone now a days seem to cache using a service locator of some sort.
    http://www.theserverside.com/discussions/thread.tss?thread_id=14992

    Interestingly, the spec never says that the home object is thread safe!

    Thanks again
    Kingshuk
  4. Agreed to some extent. Also thanks for the links . But for the second link I really think that HomeObjects/Datasources(typically immutable objects created at the start up ) need not be thread-safe as far as they are immutable objects .

    Cheers
    Deb