Anomalie in default optimistic locking in 1.1.0

[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.
// */