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
[EMAIL PROTECTED]
// /*
You know things are getting a little fishy when you're commenting out
comments.
// */
