Eric:
You are right, I use "stateless" bean for my applications.
Is there any URLs about "DAO" ? if you know,Can you send me an email ?
Thanlk you.
Albert Pi
Corp IS System Delivery
516-803-3762
>>> Eric Williams <[EMAIL PROTECTED]> 05/31/02 08:44AM >>>
I have also been disappointed with the EJB 2.0 specification in this
regard. It is as if everyone was so tired of debating the performance of
Entity beans, they caved in to the Local interfaces compromise. I'm
surprised that there has been a complete failure to emphasize the
performance penalty of invoking a local EJB. Although considerably less
than the penalty of a remote EJB, there is still a penalty with local EJB
method invocation. The overhead is sizeable enough to warrant large
disclaimers, such as "don't use fine-grained attribute accessors."
I have seen nothing to dissuade me that the most scalable approach to EJBs
is still stateless session beans. My preferred application architecture
remains stateless services (for business logic), combined with DAOs (for
persistent data access).
-eric
Ara Abrahamian To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
M> Subject: Re: Retrieving data from
entity beans
Sent by: A
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
05/31/2002 07:30
AM
Please respond to
Ara Abrahamian
You're quite right. I've measured a 6-10X difference. I'm disappointed
about what EJB2 expert group came up with. The CMP2 stuff ended up being
very sophisticated, and they don't support dependent objects either.
Dependent objects in PFD2 were a better approach. Can someone here
enlighten us why they've chosen this approach?
Based on all these performance/etc issues I still prefer to go the
session facade->javabean path, no use of workarounds such as value
objects or heavy beans/relations.
Ara.
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development [mailto:EJB-
> [EMAIL PROTECTED]] On Behalf Of Krishnan Subramanian
> Sent: Friday, May 31, 2002 3:06 PM
> 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".
===========================================================================
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".
