Hi Louth,
I hope the guys at Inprise did serous performance testing before
implementing the solution for updates that you described. In my view using
reflection for generating updates only for changed fields has following
drawbacks:
.- You are going to get a lot of different SQL statements which means that
database server would have to come up with the execution plan for each of
them. So you won't benefit from the statement (and execution plan) caching
performed by the DBMS. When you update all fields DBMS uses the same
statement and same execution plan all the time which is faster.
.- Running comparison through reflection against all fields in EB can be
expensive.
.- From my experience update of the individual field has negligible overhead
(as long as it is not the PK), so it should not make any difference whether
you update 5 or 10 fields.
.- Some DBMSs might be able to do this kind of optimization in the database
and not to update the field (or, more importantly, its index) if it has not
been changed. This will work much faster than doing the same thing in Java
using reflection.
I was facing the same issue when implementing persistence framework for one
of our clients (not in Java though), and after some testing we realized that
object flagging and all fields update is much faster than field by field
comparison.
Just some thoughts...
Alexander "Sasha" Ananiev
PricewaterhouseCoopers
-----Original Message-----
From: Louth, William (Exchange) [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, April 04, 2000 11:15 AM
To: [EMAIL PROTECTED]
Subject: Re: Implementing using CMP quickly runs in to
limitation...
Hi Anamitra,
I am only going to talk about my experience with IAS 4.0. Other
servers
might have some of the features I mention. They might even have
more. I
expect you will find this out after this post. I will let each
products
users report their own experience. The IAS team have geared their
product to
reducing any performance overhead associated with CMP. They believe
in some
cases that they might be even faster that session beans using jdbc.
Some of
the nice features included are:
1. Tuned Writes/Automatic read-only access detection
Basically the server uses Java reflection to inspect you entity
beans when
they are accessed within a transaction and only generates sql update
statements when they have been updated. Some other containers use
other
means for telling has something changed. Some rely on you to write
code to
flag the change. Others use flags on the method call indicating the
access
is read only. IMHO opinion the true test is the inspection of the
bean using
reflection; it just cannot go wrong with this unlike the other
options.
There are some issues with this when the fields are complex but by
and large
this will not be such a big an issue. The inspection places the
responsibility on the container instead of the developer; sounds
good to me
what do you think? Another benefit with the server is that when the
server
has to perform an sql update call it dynamically generates the SQL
prepared
statement for updating only those fields that have changed. Some
servers
generate the SQL code when you run them through their "ejb
compiler/deployer", thus they must make an sql update call for all
fields.
Question: Has anybody got any figures on what the performance hit
there is
with this over tuned write?
2. Loading/Caching State
You can flag the finder method in the server to load the state of
the beans.
This results in one SQl select call i.e. select pk, field1,
field2,....from
sometable where field1=?. Note the benefit is only achieved for
access in
the current transaction. Subsequent calls to the beans outside of
the
transaction will involve another sql select statement. So do all of
your
work in the transaction. My server also allows for a flag to be set
on a per
entity bean basis which informs the container that the state loaded
can be
used across finder calls and bean access. I believe some other
servers
support this feature too.
3. Caching Prepared Statements
see post "Re: 'local' entity beans vs dependent objects" by Jonathan
K.
Weedon [[EMAIL PROTECTED]].
I believe that in most business systems that these features will out
perform
any handcrafted jdbc stuff you can come up with. In the systems I
have
architected we have achieved better performance over the
alternatives. Best
of all you will probably cut your bug rate and have more time for
the
important things. There is still so many others design problems to
solve
without having to do this.
If you server does not have these features you should consider using
the O/R
mapping plugin or getting a better server.
kind regards,
William Louth
Note: I am talking about operational systems and not some nice
reporting
front end; its hard to get one rule to fit all situations. What you
should
try to do is think about each design issue carefully considering
what
different solutions are presented to you by your server and try to
effectively trade off all of those wonderful software metrics
against each
other. Then when you have done some analysis, prototype it. Its
better to
get burned early on than later; the scars will heal by the end of
the
project.
> -----Original Message-----
> From: Bhattacharyya, Ana
[SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 04, 2000 2:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing using CMP quickly runs in to
limitation...
>
> Hi William
> I am a bit curious about the point 3a. Well I always thought that
the way
> BMPs work in case of finders is pretty stupid making n+1 queries
instead
> of
> 1 queries. But are u sure that in case of CMP this is 1 query!!!
Is it for
> all the servers or for some specific server/vendor. Does ejb spec
say
> anything 'bout that? Also what do u think about the performance of
CMP
> compared to BMP? - I mean which one is better performant. I have
heard lot
> of views like this that --- in BMPs u can do fine tuning of the
queries
> which is not possible in case of CMP -- hence BMPs are better
performant
> that CMPs. what is ur view about this issue.
> TIA
> Anamitra
>
> -----Original Message-----
> From: Louth, William (Exchange) [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 04, 2000 6:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementing using CMP quickly runs in to
limitation...
>
>
> You have the following options depending on exactly what you join
> statement
> is doing.
>
> 1. Get a good cmp engine. The obvious. One which supports calling
stored
> procedures from the finder would be useful in the meantime until
better
> mapping tools are provided. TopLink could be an option; I am not
an expert
> user but I have heard good things about this add-on product.
>
> 2. Embed a sub-select query in your finder's where clause. This
can be
> used
> where you do know have access to the complete sql statement i.e.
the FROM
> section.
>
> 3. Create a hybrid entity bean which uses container managed
persistence
> for
> all others finders, ejb* apart from the join finder. The hybrid
can then
> do
> the one of the following:
>
> a. Issue the complete SQL statement to the database. The problems
with
> this
> are performance and maintainability. The performance of the
affectively
> bean
> managed find method is that number of SQL statements can be quite
high. If
> you find method returns 1000 primary keys this will result in 1 +
1000 SQL
> statements for the loading part. Container managed persistence can
be
> configured to reduce this to 1. The find method returns all the
state
> instead of just the primary key.
>
> b. Call another find method on the same home (same bean impl) with
some of
> the parameters and then with these beans perform some query on the
> association i.e. issues selects against the second home (if the
table maps
> to an entity bean) using the primary key of the first bean. This
work in
> the
> case ofa 1-M relationship. The benefits here is that we can
potential
> reduce
> the number of SQL calls since the first home will load the state
from a
> super set of our result set.
>
> c. Start from the other entity bean or table and work back.
>
> There is probably more ways of combining these things. The
performance of
> your system will be indicative of the number of SQL calls you
make. So
> analyse the data / key distribution and see when you can reduce it
by
> using
> the some of the above.
>
> kind regards,
>
> William Louth
>
> > -----Original Message-----
> > From: Alex Paransky [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 04, 2000 4:23 AM
> > To: [EMAIL PROTECTED]
> > Subject: Implementing using CMP quickly runs in to
limitation...
> >
> > I started to implement my system using CMP Entity Beans.
However, the
> > minute I needed to execute a JOIN in order to implement one of
the
> finder
> > methods, I realized that I have a problem. It seems, that CMP
is only
> > good
> > for TRIVIAL object relationships. The minute a query needs to
JOIN from
> > more than one table in order to execute the find, CMP shows it's
> > limitations. This means, that for all but the simplest of
objects, I
> need
> > to use BMP (which appears to be much slower). Is this what most
of you
> > have
> > found? Am I missing something when it comes to CMP?
> >
> > Thanks.
> > -AP_
> >
> >
>
==========================================================================
> > =
> > 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".
>
>
>
***********************************************************************
> Bear Stearns is not responsible for any recommendation,
solicitation,
> offer or agreement or any information about any transaction,
customer
> account or account activity contained in this communication.
>
***********************************************************************
>
>
==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation,
solicitation,
offer or agreement or any information about any transaction,
customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
