> 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.
Not if you set the appropriate transactions! For example, if your Session
bean is REQUIRES_NEW and your Entity bean is REQUIRED, then the db will be
updated just once: at the end of the txn! And on the same note, ejbLoad
will only be called once, at the beginning of the txn... Hence the wise
usage of transaction management will give you wonderful performance gains!
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Herbers, Joe
Sent: Monday, July 24, 2000 6:28 AM
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".
