Cannot merge versioned instance after flush, getting OptimisticLockExceptio

Question

Using EclipseLink 2.0.2 I cannot merge versioned object after flush, getting OptimisticLockException.
I get this:
MergeManager.mergeChangesOfCloneIntoWorkingCopy(Object) line: 490     
MergeManager.mergeChanges(Object, ObjectChangeSet) line: 267     
RepeatableWriteUnitOfWork(UnitOfWorkImpl).mergeCloneWithReferences(Object, MergeManager) line: 3523     
RepeatableWriteUnitOfWork.mergeCloneWithReferences(Object, MergeManager) line: 301     
RepeatableWriteUnitOfWork(UnitOfWorkImpl).mergeCloneWithReferences(Object, int, boolean) line: 3483     
RepeatableWriteUnitOfWork(UnitOfWorkImpl).mergeCloneWithReferences(Object, int) line: 3457     
RepeatableWriteUnitOfWork(UnitOfWorkImpl).mergeCloneWithReferences(Object) line: 3438     
Any known workaround?
After the flush the versioned object version has increase of one, then the merge code compare with the increased version; however, the original version is still available in ObjectChangeSet.initialWriteLockValue.
Since flush is an automatic thing depending of states that change often, even for similiar use case, it is expected to be transparent, so should have no effect on merge. In other words, functionality should be unchanged by the trigger of flush or by the use of other technique to get the right data like by using conform in memory.

Answer 1

My understanding is that the behavior is incompatible with the old functionality of supporting multiple merges, which by definition would always give OptimisticLockException.
Extract from: http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/b13698/oracle/toplink/sessions/UnitOfWork.html
setShouldNewObjectsBeCached
public void setShouldNewObjectsBeCached(boolean shouldNewObjectsBeCached)ADVANCED: By default new objects are not cached until the exist on the database. Occasionally if mergeClone is used on new objects and is required to allow multiple merges on the same new object, then if the new objects are not cached, each mergeClone will be interpretted as a different new object. By setting new objects to be cached mergeClone can be performed multiple times before commit. New objects cannot be cached unless they have a valid assigned primary key before being registered. New object with non-null invalid primary keys such as 0 or '' can cause problems and should not be used with this option.
I believe the current behavior come from Hibernate that have imposed many of their sematic/anti-patterns to JPA. Since Hibernate team have pushed a lot open session pattern, the current behavior is more likeable for them.
Ideally both behaviors should be supported, and supporting multiple merges and flush followed by merge should be the default.