To Bean or not to Bean....
Based on the limited amount of information provided your performance
problems and limitations are attributed in part to your design/deployment
and choice of application server. If performance and container managed
persistence support are crucial to your solution then go back and
re-evaluate your appserver choice in light of this. Do not turn your back on
entity beans.
-william
-----Original Message-----
From: Herbers, Joe [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 24, 2000 2:28 PM
To: [EMAIL PROTECTED]
Subject: EBs are slow (was Clustering)
> > >5) You cannot use dbIsShared=false and take advantage of
> > >caching of the entity beans.
> >
> > Correct, but there may be reasons in non-clustered scenarios that
> > disallow the use of dbIsShared. All a matter of system setup. But
> > the important question is, does it impact your code? (at least
> > that is the impression that the original question was)
>
> Doesn't impact the correctness but it might impact
> performance. So you may be
> relying of dbIsShared for performance. When you switched to
> clustering if you
> relied on dbIsShared=false your might take a big performance
> hit. Clustering
> is supposed to enhance salability not decrease it. Perhaps
> this is another
> warning weblogic should give. Don't rely on dbIsShared for
> performance if you
> plan to switch to a clustered system.
Yes to two points above: can't rely on dbIsShared for performance
even in non-clustered systems. If you have things like DB triggers
then you can't use dbIsShared=true (right?) Then even in your
non-clustered WebLogic server, you're going to take a big perf hit.
And *yes, this does affect your code*. We've seen that if
people coded a sess bean to create a new EB and then call all the
setters to define the content that the performance is terrible
because the EB hits the DB for each setter. If you thought the
EBs were caching, then you didn't worry. And there seems to be
a similar issue with getters, meaning an even greater impact.
Seeing this now, we're wondering why we used EBs at all - we've
started converting things over to sess beans using JDBC to
the DB to avoid this bad performance (and also because of things
like EB finders being too limited resulting in us iterating over
EBs which is also very slow). Any other solutions for these
issues with WebLogic EBs?
===========================================================================
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".
