It looks like your prayers (maybe) when EJB 2.0 is finalised (and implemented).
It has some ejb query language that looks like SQL/OQL. It is used to specify
finder methods!
Steve.
[EMAIL PROTECTED] on 25/07/2000 00:20:13
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Steven Shaw/Net)
Subject: Re: EBs are slow (was Clustering)
>> (and also because of things like EB finders being too limited resulting
in us iterating over EBs which is also >> very slow).
I am suprised that nobody to date (AFAIK) has created an utility that allows
you to specify your finder query in the easy, powerful, and relatively
well-known SQL language and then convert it to the hard, inflexible and
obscure weblogic syntax. This could be big money spinner. Maybe the task is
just to hard for us mere mortals who have been passivated by the ease of use
in other quality tools; shame on us.
-william
-----Original Message-----
From: louth,william
Sent: Monday, July 24, 2000 3:01 PM
To: 'A mailing list for Enterprise JavaBeans development'
Subject: RE: EBs are slow (was Clustering)
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".
===========================================================================
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".
