openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan Ireland" <eirel...@sybase.com>
Subject RE: Forced getter/setter access
Date Wed, 04 Apr 2007 06:04:21 GMT
Patrick,

I meant "tuned" as in not including columns in the SQL update "set"
clause if they weren't really changed by the app (even if a setter
was called, the old and new values may be the same).

The update "set" clause is 100% portable SQL.

So I'm not entirely clear what you mean by:

    "tuned" for your implementation

> -----Original Message-----
> From: Patrick Linskey [mailto:plinskey@bea.com] 
> Sent: Wednesday, 4 April 2007 5:44 p.m.
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: Forced getter/setter access
> 
> > If you are going to issue "tuned" updates to the DB, 
> determining what 
> > "really" changed (as opposed to what setter methods were
> > called) can avoid unnecessary DB overheads.
> 
> ... "tuned" for your implementation, that is. Often, business 
> needs require that a transaction involves a large number of 
> objects, and it would be unfortunate to have to compromise on 
> transaction integrity just for the sake of a particular 
> implementation. It's not just a matter of needing to 
> periodically call flush() during a tx, but rather of having 
> to design transactions that don't read too many objects.
> 
> Happily, with OpenJPA, this is a non-issue, regardless of 
> property or field access.
> 
> -Patrick
> 
> --
> Patrick Linskey
> BEA Systems, Inc. 
> 
> ______________________________________________________________
> _________
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it. 
> 
> > -----Original Message-----
> > From: Evan Ireland [mailto:eireland@sybase.com]
> > Sent: Tuesday, April 03, 2007 10:39 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: RE: Forced getter/setter access
> > 
> > Granted, but with a reasonable implementation the cost 
> should be low 
> > for:
> > 
> > "at commit / flush time compare the current values with the 
> original 
> > values to figure out what to write back to the database."
> > 
> > If you are going to issue "tuned" updates to the DB, 
> determining what 
> > "really" changed (as opposed to what setter methods were
> > called) can avoid unnecessary DB overheads.
> > 
> > Anyway at the end of the day, you must use the 
> getters/setters because 
> > the spec says so, and you should write portable apps where possible 
> > :-)
> > 
> > > -----Original Message-----
> > > From: Patrick Linskey [mailto:plinskey@bea.com]
> > > Sent: Wednesday, 4 April 2007 5:21 p.m.
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: RE: Forced getter/setter access
> > > 
> > > The main reason to support getter / setter access is for 
> > > implementations that cannot intercept field accesses. So, the 
> > > getters and setters are there so that the JPA implementation can 
> > > create a subclass of your entity type (hence the no-final-classes 
> > > rule) and track what happens as you invoke the setters 
> and getters. 
> > > In other words, your business methods become part of the JPA 
> > > implementation's domain.
> > > 
> > > So, when using property access, your contract with the 
> JPA provider 
> > > is that you'll access persistent attributes only through 
> the setters 
> > > and getters, which allows the implementation to track what you do 
> > > and when you do it. If you could directly access the underlying 
> > > state, the implementation would have no way to know what happened 
> > > during the course of a transaction. This, in turn, would 
> mean that 
> > > the implementation would have to keep a copy of every bit of data 
> > > that you read during a transaction, and then at commit / 
> flush time 
> > > compare the current values with the original values to figure out 
> > > what to write back to the database.
> > > 
> > > As it turns out, when you use OpenJPA, all your direct field 
> > > accesses are replaced with synthetic static methods 
> anyways, so from 
> > > a performance standpoint, you'll see equivalent behavior 
> either way. 
> > > In my experience, persistent domain model field access 
> performance 
> > > in tight loops is rarely actually a performance bottleneck; it's 
> > > almost always going back and forth to the database that ends up 
> > > being the bottleneck, and thus the most important place 
> to optimize.
> > > 
> > > -Patrick
> > > 
> > > --
> > > Patrick Linskey
> > > BEA Systems, Inc. 
> > > 
> > > ______________________________________________________________
> > > _________
> > > Notice:  This email message, together with any attachments, may 
> > > contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  
> > > affiliated entities,  that may be confidential,  proprietary,  
> > > copyrighted  and/or legally privileged, and is intended 
> solely for 
> > > the use of the individual or entity named in this message. If you 
> > > are not the intended recipient, and have received this message in 
> > > error, please immediately return this by email and then delete it.
> > > 
> > > > -----Original Message-----
> > > > From: Phill Moran [mailto:pjmoran@rogers.com]
> > > > Sent: Tuesday, April 03, 2007 10:02 PM
> > > > To: open-jpa-dev@incubator.apache.org
> > > > Subject: Forced getter/setter access
> > > > 
> > > > Can anyone explain why this rule is in effect:
> > > > 
> > > > When using property access, only the getter and setter
> > method for a
> > > > property should ever access the underlying persistent field
> > > directly.
> > > > Other methods,
> > > > including internal business methods in the persistent
> > > class, should go
> > > > through the getter and setter methods when manipulating
> > persistent
> > > > state. (section 2.1.4 OpenJPA manual)
> > > > 
> > > > This seems rather execution costly. If ,for instance, I
> > have a Size
> > > > class with hieght, width and length then to calculate 
> and return 
> > > > volume I suffer a three method call overhead:
> > > > return getWidth() * getLength() * getHieght();
> > > > 
> > > > This is opposed to a more efficient
> > > > 
> > > > Return height * width * length
> > > > 
> > > > Phill
> > > > 
> > > > 
> > > 
> > > Notice:  This email message, together with any attachments, may 
> > > contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  
> > > affiliated entities,  that may be confidential,  proprietary,  
> > > copyrighted  and/or legally privileged, and is intended 
> solely for 
> > > the use of the individual or entity named in this message. If you 
> > > are not the intended recipient, and have received this message in 
> > > error, please immediately return this by email and then delete it.
> > > 
> > 
> > 
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 


Mime
View raw message