Backward compatibility issue with version 1.2.1: Optimistic Lock exception is thrown when select is run on an updated object

[rahuls <ra...@gmail.com>]

I have found the following use case in which the optimistic lock exception is
always thrown.

The complete scenario is running in a single transaction.
Entities involved:
class A { int property1; }
class B {Map<Long, A> map; }

UseCase:
1) Update property1 of two entity A objects A1 and A2.
2) Add A1 and A2 to an existing entity B object B1.
3) Run a select query for A1 and A2.

Result:
Step 3) doesn't run and an Optimistic Lock Exception is thrown.

Debug results:
In the MySQL query log, i figured out that the update ran instantaneously
for A1 but not for A2. And when step 3) was executed, Optimistic Lock
Exception came up in logs, and the update query for A2 was shown in the
MySQL logs.

Observations:
1) The above use case ran fine if the update was done to single A object
instead of two.
2) This use case ran fine in the 1.0.1 version of Openjpa.

Possible cause:
1) I feel that this is happening because openjpa is caching some update
queries for optimization.

Is this a bug in openjpa or i need to change my code/configurations?
-- 
View this message in context: http://n2.nabble.com/Backward-compatibility-issue-with-version-1-2-1-Optimistic-Lock-exception-is-thrown-when-select-is-rt-tp4585281p4585281.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.