Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of plinskey@bea.com designates
 66.248.192.39 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: RE: Forced getter/setter access
Date: Tue, 3 Apr 2007 22:21:29 -0700
Message-ID: <7D856CDFE035FF45A0420ACBD71BDD6303C83691@repbex02.amer.bea.com>
In-Reply-To: <002001c77676$5689abf0$6601a8c0@tyan2400>
Thread-Topic: Forced getter/setter access
Thread-Index: Acd185rr/5zipX0ET4CwWrqDQ0qengAgd+mgAAC5soA=
References: <9810849.post@talk.nabble.com>
 <002001c77676$5689abf0$6601a8c0@tyan2400>
From: "Patrick Linskey" <plinskey@bea.com>
To: <open-jpa-dev@incubator.apache.org>

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.