hi,
we are using Eclipselink 2.3 against a legacy Oracle 10g DB. We are following their optimistic locking strategy of using the TS_LAST_MODIFIED timestamp column on the table when doing updates. For insert we use TS_CREATED timestamp column.
This is defined in a Eclipselink @MappedSuperclass like so.
@OptimisticLocking(type = OptimisticLockingType.SELECTED_COLUMNS, selectedColumns = { @Column(name = "TS_CREATED"), @Column(name = "TS_LAST_MODIFIED") })
This is used in a web app so detached entities are being merged. Wanting to check that a concurrency exception would get thrown I did the following test.
User 1 - Opens a edit page for existing record
User 2 - Opens a edit page for same existing record
User 1 - Makes changes and updates record successfully
User 2 - Makes changes and updates record successfully <-- Would have thought this throws a concurrency exception!!
The reason that User 2 saves successfully is because its TS_LAST_MODIFIED column that was modified by User 1 has the new value on the WHERE clause of User 2 update. Hence it does not pick up there is a difference.
Update 1 SQL
UPDATE REVIEW_EVENT_REGISTER SET TX_COMMENT = ?, TS_LAST_MODIFIED = ? WHERE (((KY_REVIEW_APPLICATION = ?) AND (KY_SEQ = ?)) AND ((TS_CREATED = ?) AND (TS_LAST_MODIFIED = ?)))
bind => [test 4155acvv6, **2012-03-15 15:25:51.352**, 20609, 21680, 2012-03-13 10:40:39.0, 2012-03-15 15:19:43.0]
Update 2 SQL
UPDATE REVIEW_EVENT_REGISTER SET TX_COMMENT = ?, TS_LAST_MODIFIED = ? WHERE (((KY_REVIEW_APPLICATION = ?) AND (KY_SEQ = ?)) AND ((TS_CREATED = ?) AND (TS_LAST_MODIFIED = ?)))
bind => [test 4155acvv5333333, 2012-03-15 15:26:33.368, 20609, 21680, 2012-03-13 10:40:39.0, **2012-03-15 15:25:51.0**]
I've updated the pertinent timestamp values with **. I have read of the trap where you do a find again on the entity before the merge and this results in picking up the latest values but I am definitely not doing in this case.
It is almost as if that when EclipseLInk does the merge it syncs itself with the underlying database. I have no cache or other properties defined in the persistence.xml so as bare bones as you can get.
Is this expected behaviour? Or am I missing the obvious here?
thanks for any help,
Ralph
Environment: Spring 3.1 | Tomcat 7 | Eclipselink 2.3
[Updated on: Thu, 15 March 2012 03:09]
Report message to a moderator
] 
Search
Help
Register
Login
Home
