I agree that AS must do all the work possible, but it could be very heavy in
some case.
what about, let the developper choosing ( thanks a flag "hasToBeUpdated")
and just compare the hashcode of the oldValue with newValue , and if
different hashcodes then, return true
Guillaume.
> public boolean isModified(Object oldValue, Object newValue) {
> if(oldValue == newValue) {
> return false;
> }
> if(oldValue == null ||
> newValue == null) {
> return true;
> }
> byte[] a = (byte[]) oldValue;
> byte[] b = (byte[]) newValue;
> if(a.length != b.length) {
> return true;
> }
> for(int i = 0; i < a.length; i++) {
> if(a[i] != b[i]) {
> return true;
> }
> }
> return false;
> }
>
> (Someone might suggest to Sun that adding a memcmp operation would be
> helpful, but the above code should compile pretty efficiently
> regardless.)
>
> > .- 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.
>
> Here, you need to think about not only the cost of the work being
> done, but which tier is doing the work. If I have to send bigger TCP
> packets to the database, and it needs to marshal bigger SQL requests,
> then both the network infrastructure and the database machine have
> more work to do.
>
> The problem with this approach is that neither the network
> infrastructure nor the database machine can be scaled up very far. On
> the other hand, replicating an AppServer in the middle-tier is trivial
> (at least with any competent AppServer implementation). So, I can
> have 2 or 5 or 50 AppServers machines sitting in the middle tier, all
> accessing a small number of databases over a single network. Here,
> clearly if I can move work out of the databases and out of the network
> and into one of my 2, 5, or 50 AppServers machines, I have a huge
> improvement in throughput.
>
> Hence, our architecture.
>
> </vendor>
>
> -jkw
>
> "Ananiev, Alexander" wrote:
> >
> > Hi Louth,
> >
> > I hope the guys at Inprise did serious 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
>
> ==============================================================
> =============
> 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".
