Hi Chris, I was aware of the fact that local EJBs will run only within the same JVM. However, if you cluster servers, the load balancing should still be able to dispatch requests for the same type of local EJBs to different servers, right ??
So, as far this is concerned there is NOT really a difference between remote or local. thanks Sanjeev Hegde -----Original Message----- From: Thompson, Chris [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 28, 2002 4:49 PM To: [EMAIL PROTECTED] Subject: Re: Local / Remote EJB home Yes, serialization/deserialization and interprocess communication potentially across the network (latency) is the main performance penalty. With a local interface it is an in-process call and everything is passed by reference. Most of the popular appserver vendors though have an optimization setting which will make a local call between two beans or from servlet to bean if they are both running in the same JVM process, so it is more valuable when you have an application that lives in more than one JVM (e.g. cluster). A possible performance penalty of using the Local Interface though is that the local instances cannot be load balanced across a cluster as they must run in the same JVM as their caller. In the end I think it is something people are going to have to try and then measure their overall application performance with Local Interfaces vs. Remote Interfaces. -Chris Thompson -----Original Message----- From: Ecka Kjellberg [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 26, 2002 3:36 AM Subject: Re: Local / Remote EJB home Sorry if I'm a little unclear but I was (and still is at least a little bit) confused about the purpose of the local EJBHome. I now think I understand the main reason to have them - that is performance. Because you could still use the 'remote' EJBHome instead of the local on the same server. The main performance penalty is it that the objects passed in and out are serialized? /Ecka -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Thompson, Chris Sent: den 25 februari 2002 23:25 To: [EMAIL PROTECTED] Subject: Re: Local / Remote EJB home Hi Ecka, I am not sure if I understand your second question, but the Local EJBHome object is just a parallel to the Remote EJBHome object. There is a local interface and a local home interface. The Local Client can do the same types of things with the local home interface that a Remote Client can do with the remote home interface such as create() or findXXX() EJBs, and now in EJB 2.0 one can call static class Home() methods that you have implemented. The local interfaces are a little different in that they cannot throw RemoteException so this is one way anyway whre they have to be different classes than the remote interface classes. I hope this helps, Chris Thompson Bean-test Developer http://www.empirix.com -----Original Message----- From: Ecka Kjellberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 7:12 AM Subject: Local / Remote EJB home Could someone please shortly explain the purpose of a Local EJBHome introduced in EJB 2.0? Does it not move a deployment property (what instances of an EJB to create) into the 'client'-code? Thanks/Ecka Kjellberg =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
