Need for Local Interface


Performance and scalability: Need for Local Interface

  1. Need for Local Interface (7 messages)

    It's interesting to hear that using Local interface saves the time to lookup in network if the ejb resides in the same box.

    My doubt is, if you say there are two beans both have remote and Local interfaces used.If the ejb1 wants to talk to ejb2 in a cluster environment, wat needs to be done?...use local interface then we are moving server specific not using cluster???

    1.both ejb1 and ejb2 have remote and local implementation. all the member servers of the cluster have both ejb1 and ejb2.

    Threaded Messages (7)

  2. Need for Local Interface[ Go to top ]

    If you want to talk to an EJB on a different machine in the same cluster, you must use a remote interface.

    Using a local interface forces all the inter-EJB communication to occur on a single machine. Actually, this is not a bad thing ...
  3. Need for Local Interface[ Go to top ]

    How about making all the Session Beans to have remote interfaces and Entity Beans to have only Local interfaces. This way whenever client invokes the (remote)Session Bean, a Session Bean instance (EJBObject)from one of the cluster machines will receive the request. Now that Session Bean can access required Entity Beans locally. In this case Session Beans should be used as per Session Facade pattern.
         Do you see any problem with this approach?

  4. Lousy detail[ Go to top ]

    but the Devil is in the details:

    Local interfaces can be put to use if the beans run in the same JVM (as opposed to running on the same computer). You could have multiple instances of an app server running on a single machine and you can't use Local interfaces to access EJBS across those instances.
  5. Need for Local Interface[ Go to top ]

    There are tons of people who believe that the idea of local interfaces was a very, very stupid thing. You see, **EVERY** EJB container by now is smart enough to make locals calls (and maybe with pass by reference) on EJBs with **REMOTE** interfaces when these happen to be on the same JVM of its client. It is a simple and very effective optimization that can be done by the stub code.

    So it is reasonable to infer that the placement of EJBs (local or remote) should be a deployment-time decision - not a design or run-time decision. If you have a decent EJB container you only need to use local interfaces when working with CMR on entity beans. YOU GET NO PERFORMANCE IMPROVEMENT WHEN USING LOCAL INTERFACES ON SESSION BEANS - that is, I repeat, if you have a decent app server.
  6. Not a Conclusion[ Go to top ]

    The reason behind this questions is that, In any enterprise application deployment, beans are deployed in a Horizontal cluster(meaning all the servers in the clusters resides in different JVM) then wat is the benefit of using local interface, any way it's no more single JVM.Please correct me folks, if i am wrong...
  7. Not a Conclusion[ Go to top ]

    Cross-JVM calls are still more expensive than intra-JVM calls, so there is still a benefit to being able to control that with local interfaces.
  8. Not a Conclusion[ Go to top ]

    The existence of clusters should be irrelevant in this matter. Again, a decent container MUST be able to perceive if an appropriate EJB is available on the same JVM, making local calls (no matter if you are using remote interfaces or not). If the EJB to be used is somewhere else, then the container will decide dynamically to use RMI.

    Again, the placement of EJBs (with or without clusters) should NOT be a design-time decision, but indeed a deployment-time decision.

    Of course intra-JVM calls are faster. The point is: it should be up to the container to decide when to use them. Bringing such a decision to the design isn't right, and brings no benefit at all, if you assume that the EJB container can make "remote" interface calls perform as fast as local when the EJB is in the same JVM of its client.