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".
