Milind, Nice one. This is a good example of the potential pitfalls of using local interfaces in a web application.
A common misinterpretation seems to be that using local interfaces in a web application will speed up things. This might very much be the case [depending on your vendor implementation]. In a typical web application using EJBs, you probably want to run your EJBs and JSPs (EJB & Web Container if you prefer) in the same process for performance reasons. But some of the (perceived) performance benefits of local interfaces can be illusory. For one, certain AppServers (at least we do) optimize calls between EJBs or to EJBs if they are in the same JVM even if using Remote Interfaces. In our product for example, since we already optimize co-located calls and use pass-by-reference semantics (there is a runtime flag to turn this optimization off), there are [no performance differences] between local & remote interfaces for intra-vm calls. Another subtle - but not apparent issue when using local interfaces is when you start clustering. Using local interfaces in your web application forces a 1:1 ratio between web & ejb containers. But in normal cases the number of web containers usually exceeds the number of ejb containers. Or, for security reasons, your admin wants the EJB Container to run inside the local network, while the Web Container runs on the outside along with your web server. As you found out, placing references to local EJBs in a web session object is problematic, since these references are not serializable in the IIOP (or even Java) sense. And some AppServers might persist session objects for high-availab- ility & failovers, in which case, attempting to persist these session objects would fail! My (personal) opinion is that you'd want to use local interfaces for entity beans only. Your session facades should declare remote interfaces and these would be used by your client apps (web app, java client app, etc). If you happen to run the Web & EJB Container in the same process, the AppServer runtime should be intelligent enough (if not the case, move to an AppServer that is ;) to optimize intra-vm calls to local ones even if using remote interfaces. I'd be interested in hearing others thoughts on this. -krish Borland > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Milind Kulkarni > Sent: 20 December 2002 14:36 > To: [EMAIL PROTECTED] > Subject: Remote Interface Vs. Local Interfaces (getHandle) > > > Hi All, > > It seems that getHandle method is not available if you use > Local Interfaces > (EJBLocalObject) though this method is available if we use remote > interface (EJBObject). In my previous project we had stored > the handle of > stateful ejb in the HttpSession and we use to get an handle > to Stateful > session bean by using getHandle method. > > Now we have decided to use Session Facade ( a stateful bean) > so as to take > the advantage of Local Interfaces. How do we handle this > situation now? > > Regards, > Milind > > ============================================================== > ============= > 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".
