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

Reply via email to