Ignoring dynamically typed methods of data transfer for a moment, I totally agree with you. I have also measured the overhead of local calls to EJBs in a popular J2EE impementation and found a 10,000:1 difference between them and normal local function calls. I.e. calls to EJBs are slow; use them sparingly. Note that the implementation I tested did not have EJB 2.0 local interfaces.
Mike Bresnahan > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Krishnan Subramanian > Sent: Friday, May 31, 2002 5:36 AM > To: [EMAIL PROTECTED] > Subject: Retrieving data from entity beans > > > I was going through the EJB Design Patterns book by Floyd & > came across this pattern I'd like to debate further: > > It recommends the use of fine grained accessor methods to get > data from a local EJB 2.0 entity bean. That is, not to use > value objects (or the likes) to perform bulk a get/set but to > instead use fine-grained accessor methods. > > However, the implicit assumption here seems to be that fine > grained accessor methods on local entity beans incur > approximately the same overhead as that of method calls on > local objects. Which is certainly not true. The Container > still has to perform checks on whether the method was invoked > in the right transactional & security context etc. That by > no means comes for free. > > In typical tests involving popular application servers, I've > found that the overhead of fine-grained access is approximately > 8x - 15x times that of those involving bulk gets/sets using value > objects (or the likes). For a small number of clients [& a small > number of persistent fields], this might not seem to be much of > an overhead (since the overhead of a remote call to a session > facade will mask a lot of intra-vm communication overhead), but > when you start accessing a large number of entity beans in the > scope of a transaction and/or start increasing the load on the > system, the overhead of using fine-grained accessors will rear > its head. > > Now, the question is not whether I need to eliminate the fine > grained accessor/mutator methods but rather the age old question > of Performance vs Modularity+Maintainability. > > Since entity beans typically add overhead (yes, even with local > interfaces!), I'd recommend the use of a bulk get to transfer > data between the local entity bean & the session facade when > accessing a majority of the persistent fields. This probably > would be make sense now that popular Containers vendors are > recommending the use of entity beans & are enhancing their > persistent managers to make entity beans better performant. > > On the other hand, if the client (session facade or whatever) > needs only a subset of the persistent fields then probably > fine-grained/ejbSelect methods can be used. > > Adding a bulk getter (or setter) does introduce some overhead > in terms of the maintainability of the application - but a lot > of IDEs, code-generators & code-templates can make this step > redundant. And this bulk-getter can co-exist with fine-grained > accessor methods which (as mentioned above) can be used in > other use-cases. > > Comments? > > -krish > > ================================================================== > ========= > 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".