You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Phill Moran <pj...@rogers.com> on 2007/04/04 07:01:42 UTC
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
RE: Forced getter/setter access
Posted by Patrick Linskey <pl...@bea.com>.
Ah... I was referring to the fact that if an implementation isn't
tracking field accesses, then it must sit around and do in-mem
comparisons (and hold onto hard refs to copies of all read data) in
order to figure out what to write back to the DB. So, I was referring
solely to the in-mem computation time, not to SQL generation.
-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 11:04 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: Forced getter/setter access
>
> 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.
> >
>
>
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.
RE: Forced getter/setter access
Posted by Evan Ireland <ei...@sybase.com>.
Ok, this sounds good.
> -----Original Message-----
> From: Abe White [mailto:awhite@bea.com]
> Sent: Thursday, 5 April 2007 2:29 a.m.
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Forced getter/setter access
>
>
> > 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).
>
> We detect when you're setting a field/property to the same
> value it already has. That doesn't require a state snapshot
> or comparisons at flush time. It just requires passing the
> current value along with the new value to the internal method
> that is responsible for "dirtying" the object.
>
> 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.
>
Re: Forced getter/setter access
Posted by Abe White <aw...@bea.com>.
> 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).
We detect when you're setting a field/property to the same value it
already has. That doesn't require a state snapshot or comparisons at
flush time. It just requires passing the current value along with
the new value to the internal method that is responsible for
"dirtying" the object.
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.
RE: Forced getter/setter access
Posted by Evan Ireland <ei...@sybase.com>.
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.
>
RE: Forced getter/setter access
Posted by Patrick Linskey <pl...@bea.com>.
> 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.
RE: Forced getter/setter access
Posted by Evan Ireland <ei...@sybase.com>.
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.
>
RE: Forced getter/setter access
Posted by Patrick Linskey <pl...@bea.com>.
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.