Just out of curiousity do you know exactly what this overhead is? Is it the old load/store problem? Is there something that a future spec could do so that fine-grained accessors from a local entity can perform close to bulk accessors or is it just the nature of the beast?
>From: Krishnan Subramanian <[EMAIL PROTECTED]> >Reply-To: Krishnan Subramanian <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Retrieving data from entity beans >Date: Fri, 31 May 2002 12:36:03 +0200 > >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". > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com =========================================================================== 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".
