You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Tedman Leung <te...@sfu.ca> on 2008/05/07 19:11:57 UTC
update always called on commits (still)
Hi while back we had a discussion on updates (or more specifically
preupdates) always being called even when no changes where made.
I noticed there was an issue OPENJPA-506 openned for this and currently
closed - but this still occurs.
Both anotated @PreUpdate methods as well as updates are always called even
on read only operations.
Does anyone know if this is considered an open issue or a fixed issue?
I'm running OpenJPA 1.1 checkout from SVN on April 28th, 2008 which is
long after the fixed date of Feb 1 2008.
This is now causing me even worst problems due to a recent change in my
application where I switched from using @PreUpdate to @Version to keep
track of the last updated time of an object. Previously the lastUpdated
field was useless because it was just the last time some one read the
object, now it's throwing OptimisticLockException because requests are
thinking some one else updated the object (when in reality it was just
readonly).
--
Ted Leung
tedman@sfu.ca
You know you're in trouble when snow starts to clog your ram jets.
Anomalie in default optimistic locking in 1.1.0
Posted by Tedman Leung <te...@sfu.ca>.
I've encountered an anomalie with the optimistic locking.
OpenJpa 1.1.0 : from repo1.maven.org
Jdk : java full version "1.6.0_06-b02"
Spring 2.5.4
compile time enhancement using org.apache.openjpa.ant.PCEnhancerTask ant
task
The issue is that if I call merge() on an object after changing a value -
but the actual value is the same, and there's no version field, an
Optimistic lock exception is thrown.
i.e. (bits of the class were cut out for brevity)
@Entity
public class IncidentItemDetails
{
@EmbeddedId
private IncidentItemPrimaryKey id = null;
private String description = null;
private Integer repairCost = null;
}
if I do
IncidentItemDetails x=new IncidentItemDetails(primaryKey);
x.setRepairCost(1234);
persist(x);
IncidentItemDetails x1=find(primaryKey);
x1.setRepairCost(x.getRepairCost());
merge(x1);
I will get the following :
<openjpa-1.1.0-r422266:657916 nonfatal store error>
org.apache.openjpa.persistence.OptimisticLockException: Optimistic locking
errors were detected when flushing to the data store. The following
objects may have been concurrently modified in another transaction:
[....IncidentItemDetails-....IncidentItemDetails-incidentId=1, itemId=3]
Note this only happens if you set it to the same value (but different
reference), i.e. if I changed the cost to something else like 99999,
everything works fine. Everything also works fine if I just don't set the
value and call merge.
This came up however because the value is user input so I just set the
value to what ever the user entered, even if it happened to be the same as
the previous value.
As a work around, all I had to do was add an
@Version
private Timestamp lastUpdated = null;
field to my object, but in the case I really didn't have any use for the
timestamp so I didn't originally have it, and considering my table was
only 4 small columns, this adds a lot of over head to my rows.
So, everything works for me now, but I figured I should report this as
this doesn't seem like expected behaviour.
--
Ted Leung
tedman@sfu.ca
// /*
You know things are getting a little fishy when you're commenting out
comments.
// */
Re: update always called on commits (still)
Posted by Tedman Leung <te...@sfu.ca>.
I did read some where that the Tomcat classloader may be preventing
runtime enhancments to the classes, so it may not necessarily be different
code but it might be the fall back mentioned in section 5.2.4, so
even though I thought I was getting byte code enhancement with jdk1.6, I
wasn't and I was only getting "state comparison and subclassing".
> A question to the OpenJPA developers: regarding different types of byte
> code enhancement and the disparity in functionality between them, does this
> reflect a seperate code base for enhanced versus non-enhanced OpenJPA?
>
>
>
> Tedman Leung on 07/05/08 22:01, wrote:
> >I eventually did compile time enhancement (as the agent was way too
> >problemmatic) and yeah all my problems went away. Thanks for the info.
> >
> >
> >
> >On Wed, May 07, 2008 at 11:35:55AM -0700, Tedman Leung wrote:
> >>Well according to the documentation "unenhanced" will become enhanced at
> >>runtime via "Deploy-time enhancement", "Java 6 class retransformation",
> >>"Java 5 class redefinition".
> >>
> >>I think what I was getting from Michael's posting is that the automatic
> >>enhancement #3 has issues so right now I'm trying to weigh option #1 and
> >>option #2.
> >>
> >>I originally thought option #2 would be simple but unfortunately it's not
> >>as it requires all the jars to be in the initial classpath which means
> >>I'm now messing with tomcat's original classpath and maintaining a
> >>classpath outside of the automatically generated WEB-INF/lib/* ...
> >>
> >>
> >>
> >>>Just to clarify, I believe there are three possible enhancement
> >>>scenarios:
> >>>
> >>>1. build-time enhancement - running
> >>>org.apache.openjpa.enhance.PCEnhancer over your bytecode before you run
> >>>your app.
> >>>
> >>>2. runtime enhancement - giving the "-javaagent=openjpa.jar" argument to
> >>>the JVM when you run your app.
> >>>
> >>>3. unenhanced - neither 1 nor 2.
> >>>
> >>>Have you observed this problem in all three scenarios? Just (2) or (3)?
>
--
Ted Leung
tedman@sfu.ca
You know you're in trouble when snow starts to clog your ram jets.
Re: update always called on commits (still)
Posted by Adam Hardy <ad...@cyberspaceroad.org>.
A question to the OpenJPA developers: regarding different types of byte code
enhancement and the disparity in functionality between them, does this reflect a
seperate code base for enhanced versus non-enhanced OpenJPA?
Tedman Leung on 07/05/08 22:01, wrote:
> I eventually did compile time enhancement (as the agent was way too
> problemmatic) and yeah all my problems went away. Thanks for the info.
>
>
>
> On Wed, May 07, 2008 at 11:35:55AM -0700, Tedman Leung wrote:
>> Well according to the documentation "unenhanced" will become enhanced at
>> runtime via "Deploy-time enhancement", "Java 6 class retransformation",
>> "Java 5 class redefinition".
>>
>> I think what I was getting from Michael's posting is that the automatic
>> enhancement #3 has issues so right now I'm trying to weigh option #1 and
>> option #2.
>>
>> I originally thought option #2 would be simple but unfortunately it's not
>> as it requires all the jars to be in the initial classpath which means I'm
>> now messing with tomcat's original classpath and maintaining a classpath
>> outside of the automatically generated WEB-INF/lib/* ...
>>
>>
>>
>>> Just to clarify, I believe there are three possible enhancement scenarios:
>>>
>>> 1. build-time enhancement - running
>>> org.apache.openjpa.enhance.PCEnhancer over your bytecode before you run
>>> your app.
>>>
>>> 2. runtime enhancement - giving the "-javaagent=openjpa.jar" argument to
>>> the JVM when you run your app.
>>>
>>> 3. unenhanced - neither 1 nor 2.
>>>
>>> Have you observed this problem in all three scenarios? Just (2) or (3)?
Re: update always called on commits (still)
Posted by Tedman Leung <te...@sfu.ca>.
I eventually did compile time enhancement (as the agent was way too
problemmatic) and yeah all my problems went away. Thanks for the info.
On Wed, May 07, 2008 at 11:35:55AM -0700, Tedman Leung wrote:
> Well according to the documentation "unenhanced" will become enhanced at
> runtime via "Deploy-time enhancement", "Java 6 class retransformation",
> "Java 5 class redefinition".
>
> I think what I was getting from Michael's posting is that the automatic
> enhancement #3 has issues so right now I'm trying to weigh option #1 and
> option #2.
>
> I originally thought option #2 would be simple but unfortunately it's not
> as it requires all the jars to be in the initial classpath which means I'm
> now messing with tomcat's original classpath and maintaining a classpath
> outside of the automatically generated WEB-INF/lib/* ...
>
>
>
> > Just to clarify, I believe there are three possible enhancement scenarios:
> >
> > 1. build-time enhancement - running
> > org.apache.openjpa.enhance.PCEnhancer over your bytecode before you run
> > your app.
> >
> > 2. runtime enhancement - giving the "-javaagent=openjpa.jar" argument to
> > the JVM when you run your app.
> >
> > 3. unenhanced - neither 1 nor 2.
> >
> > Have you observed this problem in all three scenarios? Just (2) or (3)?
> >
> > Tedman Leung wrote:
> > >well, yes I'm running int "unenhanced" or in "runtime enhancement",
> > >however, I thought at was a valid way of running the system. I didn't find
> > >any documentation saying not to use that mode and it was much more
> > >"convenient" so I chose that route.
> > >
> > >
> > >
> > >On Wed, May 07, 2008 at 07:30:49PM +0200, Michael Vorburger wrote:
> > >>I'm sure it's not that simple, but you aren't maybe by chance not using
> > >>enhancement (build or that -javaagent) and relying on the OpenJPA
> > >>feature that allows to run even unenhanced in some kind of degraded mode
> > >>(there is a log at the beginning if you're in that mode), and we noticed
> > >>that "change tracking" seems very unreliable in that mode, and you
> > >>easily get unncessarry SQL UPDATE statements. Note also the
> > >>https://issues.apache.org/jira/browse/OPENJPA-507.
> > >>
> > >>If you're sure you're enhancing (correctly; not e.g. having Eclipse
> > >>overwrite your .class), this is surely something else; sorry.
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Tedman Leung [mailto:tedman@sfu.ca]
> > >>Sent: mercredi, 7. mai 2008 19:12
> > >>To: users@openjpa.apache.org
> > >>Subject: update always called on commits (still)
> > >>
> > >>Hi while back we had a discussion on updates (or more specifically
> > >>preupdates) always being called even when no changes where made.
> > >>
> > >>I noticed there was an issue OPENJPA-506 openned for this and currently
> > >>closed - but this still occurs.
> > >>
> > >>Both anotated @PreUpdate methods as well as updates are always called
> > >>even on read only operations.
> > >>
> > >>Does anyone know if this is considered an open issue or a fixed issue?
> > >>
> > >>I'm running OpenJPA 1.1 checkout from SVN on April 28th, 2008 which is
> > >>long after the fixed date of Feb 1 2008.
> > >>
> > >>This is now causing me even worst problems due to a recent change in my
> > >>application where I switched from using @PreUpdate to @Version to keep
> > >>track of the last updated time of an object. Previously the lastUpdated
> > >>field was useless because it was just the last time some one read the
> > >>object, now it's throwing OptimisticLockException because requests are
> > >>thinking some one else updated the object (when in reality it was just
> > >>readonly).
> > >>
> > >>--
> > >> Ted Leung
> > >> tedman@sfu.ca
> > >>
> > >>You know you're in trouble when snow starts to clog your ram jets.
> > >>
> > >>____________________________________________________________
> > >>
> > >>? This email and any files transmitted with it are CONFIDENTIAL and
> > >>intended
> > >> solely for the use of the individual or entity to which they are
> > >> addressed.
> > >>? Any unauthorized copying, disclosure, or distribution of the material
> > >>within
> > >> this email is strictly forbidden.
> > >>? Any views or opinions presented within this e-mail are solely those of
> > >>the
> > >> author and do not necessarily represent those of Odyssey Financial
> > >>Technologies SA unless otherwise specifically stated.
> > >>? An electronic message is not binding on its sender. Any message
> > >>referring to
> > >> a binding engagement must be confirmed in writing and duly signed.
> > >>? If you have received this email in error, please notify the sender
> > >>immediately
> > >> and delete the original.
> > >
>
> --
> Ted Leung
> tedman@sfu.ca
>
> You know you're in trouble when snow starts to clog your ram jets.
--
Ted Leung
tedman@sfu.ca
You know you're in trouble when snow starts to clog your ram jets.
Re: update always called on commits (still)
Posted by Tedman Leung <te...@sfu.ca>.
Well according to the documentation "unenhanced" will become enhanced at
runtime via "Deploy-time enhancement", "Java 6 class retransformation",
"Java 5 class redefinition".
I think what I was getting from Michael's posting is that the automatic
enhancement #3 has issues so right now I'm trying to weigh option #1 and
option #2.
I originally thought option #2 would be simple but unfortunately it's not
as it requires all the jars to be in the initial classpath which means I'm
now messing with tomcat's original classpath and maintaining a classpath
outside of the automatically generated WEB-INF/lib/* ...
> Just to clarify, I believe there are three possible enhancement scenarios:
>
> 1. build-time enhancement - running
> org.apache.openjpa.enhance.PCEnhancer over your bytecode before you run
> your app.
>
> 2. runtime enhancement - giving the "-javaagent=openjpa.jar" argument to
> the JVM when you run your app.
>
> 3. unenhanced - neither 1 nor 2.
>
> Have you observed this problem in all three scenarios? Just (2) or (3)?
>
> Tedman Leung wrote:
> >well, yes I'm running int "unenhanced" or in "runtime enhancement",
> >however, I thought at was a valid way of running the system. I didn't find
> >any documentation saying not to use that mode and it was much more
> >"convenient" so I chose that route.
> >
> >
> >
> >On Wed, May 07, 2008 at 07:30:49PM +0200, Michael Vorburger wrote:
> >>I'm sure it's not that simple, but you aren't maybe by chance not using
> >>enhancement (build or that -javaagent) and relying on the OpenJPA
> >>feature that allows to run even unenhanced in some kind of degraded mode
> >>(there is a log at the beginning if you're in that mode), and we noticed
> >>that "change tracking" seems very unreliable in that mode, and you
> >>easily get unncessarry SQL UPDATE statements. Note also the
> >>https://issues.apache.org/jira/browse/OPENJPA-507.
> >>
> >>If you're sure you're enhancing (correctly; not e.g. having Eclipse
> >>overwrite your .class), this is surely something else; sorry.
> >>
> >>
> >>-----Original Message-----
> >>From: Tedman Leung [mailto:tedman@sfu.ca]
> >>Sent: mercredi, 7. mai 2008 19:12
> >>To: users@openjpa.apache.org
> >>Subject: update always called on commits (still)
> >>
> >>Hi while back we had a discussion on updates (or more specifically
> >>preupdates) always being called even when no changes where made.
> >>
> >>I noticed there was an issue OPENJPA-506 openned for this and currently
> >>closed - but this still occurs.
> >>
> >>Both anotated @PreUpdate methods as well as updates are always called
> >>even on read only operations.
> >>
> >>Does anyone know if this is considered an open issue or a fixed issue?
> >>
> >>I'm running OpenJPA 1.1 checkout from SVN on April 28th, 2008 which is
> >>long after the fixed date of Feb 1 2008.
> >>
> >>This is now causing me even worst problems due to a recent change in my
> >>application where I switched from using @PreUpdate to @Version to keep
> >>track of the last updated time of an object. Previously the lastUpdated
> >>field was useless because it was just the last time some one read the
> >>object, now it's throwing OptimisticLockException because requests are
> >>thinking some one else updated the object (when in reality it was just
> >>readonly).
> >>
> >>--
> >> Ted Leung
> >> tedman@sfu.ca
> >>
> >>You know you're in trouble when snow starts to clog your ram jets.
> >>
> >>____________________________________________________________
> >>
> >>? This email and any files transmitted with it are CONFIDENTIAL and
> >>intended
> >> solely for the use of the individual or entity to which they are
> >> addressed.
> >>? Any unauthorized copying, disclosure, or distribution of the material
> >>within
> >> this email is strictly forbidden.
> >>? Any views or opinions presented within this e-mail are solely those of
> >>the
> >> author and do not necessarily represent those of Odyssey Financial
> >>Technologies SA unless otherwise specifically stated.
> >>? An electronic message is not binding on its sender. Any message
> >>referring to
> >> a binding engagement must be confirmed in writing and duly signed.
> >>? If you have received this email in error, please notify the sender
> >>immediately
> >> and delete the original.
> >
--
Ted Leung
tedman@sfu.ca
You know you're in trouble when snow starts to clog your ram jets.
Re: update always called on commits (still)
Posted by Andy Schlaikjer <ha...@cs.cmu.edu>.
Just to clarify, I believe there are three possible enhancement scenarios:
1. build-time enhancement - running
org.apache.openjpa.enhance.PCEnhancer over your bytecode before you run
your app.
2. runtime enhancement - giving the "-javaagent=openjpa.jar" argument to
the JVM when you run your app.
3. unenhanced - neither 1 nor 2.
Have you observed this problem in all three scenarios? Just (2) or (3)?
Tedman Leung wrote:
> well, yes I'm running int "unenhanced" or in "runtime enhancement",
> however, I thought at was a valid way of running the system. I didn't find
> any documentation saying not to use that mode and it was much more
> "convenient" so I chose that route.
>
>
>
> On Wed, May 07, 2008 at 07:30:49PM +0200, Michael Vorburger wrote:
>> I'm sure it's not that simple, but you aren't maybe by chance not using
>> enhancement (build or that -javaagent) and relying on the OpenJPA
>> feature that allows to run even unenhanced in some kind of degraded mode
>> (there is a log at the beginning if you're in that mode), and we noticed
>> that "change tracking" seems very unreliable in that mode, and you
>> easily get unncessarry SQL UPDATE statements. Note also the
>> https://issues.apache.org/jira/browse/OPENJPA-507.
>>
>> If you're sure you're enhancing (correctly; not e.g. having Eclipse
>> overwrite your .class), this is surely something else; sorry.
>>
>>
>> -----Original Message-----
>> From: Tedman Leung [mailto:tedman@sfu.ca]
>> Sent: mercredi, 7. mai 2008 19:12
>> To: users@openjpa.apache.org
>> Subject: update always called on commits (still)
>>
>> Hi while back we had a discussion on updates (or more specifically
>> preupdates) always being called even when no changes where made.
>>
>> I noticed there was an issue OPENJPA-506 openned for this and currently
>> closed - but this still occurs.
>>
>> Both anotated @PreUpdate methods as well as updates are always called
>> even on read only operations.
>>
>> Does anyone know if this is considered an open issue or a fixed issue?
>>
>> I'm running OpenJPA 1.1 checkout from SVN on April 28th, 2008 which is
>> long after the fixed date of Feb 1 2008.
>>
>> This is now causing me even worst problems due to a recent change in my
>> application where I switched from using @PreUpdate to @Version to keep
>> track of the last updated time of an object. Previously the lastUpdated
>> field was useless because it was just the last time some one read the
>> object, now it's throwing OptimisticLockException because requests are
>> thinking some one else updated the object (when in reality it was just
>> readonly).
>>
>> --
>> Ted Leung
>> tedman@sfu.ca
>>
>> You know you're in trouble when snow starts to clog your ram jets.
>>
>> ____________________________________________________________
>>
>> ? This email and any files transmitted with it are CONFIDENTIAL and intended
>> solely for the use of the individual or entity to which they are addressed.
>> ? Any unauthorized copying, disclosure, or distribution of the material within
>> this email is strictly forbidden.
>> ? Any views or opinions presented within this e-mail are solely those of the
>> author and do not necessarily represent those of Odyssey Financial
>> Technologies SA unless otherwise specifically stated.
>> ? An electronic message is not binding on its sender. Any message referring to
>> a binding engagement must be confirmed in writing and duly signed.
>> ? If you have received this email in error, please notify the sender immediately
>> and delete the original.
>
Re: update always called on commits (still)
Posted by Tedman Leung <te...@sfu.ca>.
well, yes I'm running int "unenhanced" or in "runtime enhancement",
however, I thought at was a valid way of running the system. I didn't find
any documentation saying not to use that mode and it was much more
"convenient" so I chose that route.
On Wed, May 07, 2008 at 07:30:49PM +0200, Michael Vorburger wrote:
> I'm sure it's not that simple, but you aren't maybe by chance not using
> enhancement (build or that -javaagent) and relying on the OpenJPA
> feature that allows to run even unenhanced in some kind of degraded mode
> (there is a log at the beginning if you're in that mode), and we noticed
> that "change tracking" seems very unreliable in that mode, and you
> easily get unncessarry SQL UPDATE statements. Note also the
> https://issues.apache.org/jira/browse/OPENJPA-507.
>
> If you're sure you're enhancing (correctly; not e.g. having Eclipse
> overwrite your .class), this is surely something else; sorry.
>
>
> -----Original Message-----
> From: Tedman Leung [mailto:tedman@sfu.ca]
> Sent: mercredi, 7. mai 2008 19:12
> To: users@openjpa.apache.org
> Subject: update always called on commits (still)
>
> Hi while back we had a discussion on updates (or more specifically
> preupdates) always being called even when no changes where made.
>
> I noticed there was an issue OPENJPA-506 openned for this and currently
> closed - but this still occurs.
>
> Both anotated @PreUpdate methods as well as updates are always called
> even on read only operations.
>
> Does anyone know if this is considered an open issue or a fixed issue?
>
> I'm running OpenJPA 1.1 checkout from SVN on April 28th, 2008 which is
> long after the fixed date of Feb 1 2008.
>
> This is now causing me even worst problems due to a recent change in my
> application where I switched from using @PreUpdate to @Version to keep
> track of the last updated time of an object. Previously the lastUpdated
> field was useless because it was just the last time some one read the
> object, now it's throwing OptimisticLockException because requests are
> thinking some one else updated the object (when in reality it was just
> readonly).
>
> --
> Ted Leung
> tedman@sfu.ca
>
> You know you're in trouble when snow starts to clog your ram jets.
>
> ____________________________________________________________
>
> ? This email and any files transmitted with it are CONFIDENTIAL and intended
> solely for the use of the individual or entity to which they are addressed.
> ? Any unauthorized copying, disclosure, or distribution of the material within
> this email is strictly forbidden.
> ? Any views or opinions presented within this e-mail are solely those of the
> author and do not necessarily represent those of Odyssey Financial
> Technologies SA unless otherwise specifically stated.
> ? An electronic message is not binding on its sender. Any message referring to
> a binding engagement must be confirmed in writing and duly signed.
> ? If you have received this email in error, please notify the sender immediately
> and delete the original.
--
Ted Leung
tedman@sfu.ca
You know you're in trouble when snow starts to clog your ram jets.
RE: update always called on commits (still)
Posted by Michael Vorburger <mv...@odyssey-group.com>.
I'm sure it's not that simple, but you aren't maybe by chance not using
enhancement (build or that -javaagent) and relying on the OpenJPA
feature that allows to run even unenhanced in some kind of degraded mode
(there is a log at the beginning if you're in that mode), and we noticed
that "change tracking" seems very unreliable in that mode, and you
easily get unncessarry SQL UPDATE statements. Note also the
https://issues.apache.org/jira/browse/OPENJPA-507.
If you're sure you're enhancing (correctly; not e.g. having Eclipse
overwrite your .class), this is surely something else; sorry.
-----Original Message-----
From: Tedman Leung [mailto:tedman@sfu.ca]
Sent: mercredi, 7. mai 2008 19:12
To: users@openjpa.apache.org
Subject: update always called on commits (still)
Hi while back we had a discussion on updates (or more specifically
preupdates) always being called even when no changes where made.
I noticed there was an issue OPENJPA-506 openned for this and currently
closed - but this still occurs.
Both anotated @PreUpdate methods as well as updates are always called
even on read only operations.
Does anyone know if this is considered an open issue or a fixed issue?
I'm running OpenJPA 1.1 checkout from SVN on April 28th, 2008 which is
long after the fixed date of Feb 1 2008.
This is now causing me even worst problems due to a recent change in my
application where I switched from using @PreUpdate to @Version to keep
track of the last updated time of an object. Previously the lastUpdated
field was useless because it was just the last time some one read the
object, now it's throwing OptimisticLockException because requests are
thinking some one else updated the object (when in reality it was just
readonly).
--
Ted Leung
tedman@sfu.ca
You know you're in trouble when snow starts to clog your ram jets.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.