DomainObject.merge doesn't appear to work for Hibernate domain object - get OptimisticLockingException - Grails 6.2.3 & 7.0.0-M5 possibly others

[boardbloke]

Expected Behavior

I have a detached object A with optimistic locking where the object has changed in another HibernateSession.

I call merge on the detached instance to get a new persistent instance B that has the dirty fields from the detached object A copied over.

If I call save on that, I would expect when the Hibernate Session gets flushed, B will cause a successful save.

Actual Behaviour

Object B in the above does not have the value of the version property set to what is in the DB for the object, it has retained the value that object A had.

When the changes in Object B is flushed - it fails because the version column value is included in the update where clause with a value that does not represent what is on the DB.

Steps To Reproduce

ExampleApp.zip provided
Run the supplied integration test

exampleApp.zip

Environment Information

WSL2
Java 17

Example Application

No response

Version

6.2.3
7.0.0-M5

[jamesfredley]

At the end you should call save on ds2Copy, not ds2 which is still detached, stale and unchanged.

// Now call merge and save and see what happens
Example.withNewTransaction {
    Example ds2Copy = ds2.merge(flush: false)  // Merge; do not flush yet

    assert ds2Copy.name == 'example3'
    assert ds2Copy.version == 1

    ds2Copy.save(flush: true)  // Save the merged instance
}

[boardbloke]

Are you saying you made that change to the example app amd it worked?

[jamesfredley]

I believe that will resolve your issue, if you re-test it.

[boardbloke]

exampleApp.zip

HI @jamesfredley - I've made the change to the example test code (soz - operator error there), but it doesn't fix the problem.

Using the example app, note the assert assert ds2Copy.version == 1 in ExampleService.exampleMerge fails. I think this should not fail, because the value of version in the DB is 1 at that point. ds2Copy is an attached object that should represent what is stored on the DB at that point, but it has an incorrect value for the version property.

If you comment out that assertion in ExampleService and run the test again, then when ds2Copy is flushed by the withTransaction implementation it fails with a HibernateOptimisticLockingFailureException.

This is not surprising given the previous problem, but is not expected. I think the flush should work.

So - the problem I think is the call to ds2.merge() is not returning an attached instance that correctly reflects the DB at the point it is called.

I've included an amended example app.

[boardbloke]

Also find attached a simpler example app that has a domain object with no associations or complication, and a few more steps to demonstrate that merge seems to not work as expected

exampleAppSimple.zip

[jamesfredley]

Based on https://www.baeldung.com/hibernate-save-persist-update-merge-saveorupdate#3-merge, ds2Copy.version is likely getting pulled from the database and then overwritten with ds2.version.

See if this shows that behavior

ds2.version = 6
// Use merge to get an attached instance from the detached ds2.
Example ds2Copy = ds2.merge()

assert ds2Copy.isAttached()
assert ds2Copy.name == 'example3'

assert ds2Copy.version == 6

[boardbloke]

Hi @jamesfredley ,

Thanks for replying! I think you are correct in your analysis, but the code you suggest does not help highlight the problem. I tried it anyway, but it gives what i expected it would, the assert passes, but the flush that is called by the withTransaction implementation still causes HibernateOptimisticLockingFailureException.

The reason it doesn't highlight the issue is the merge call is supposed to load a new, attached, instance into the Hibernate session (ds2Copy) and then copy the "dirty" properties of the detached object (ds2) into the attached instance.

But when the changes to the attached instance are flushed, the SQL that Hibernate constructs will include a WHERE clause that contains the original value of the version property. So changing the value of version on the attached instance doesn't help - as that's not the value used by Hibernate in the WHERE clause.

Regardless, I think you are correct that the the implementation of merge is (incorrectly IMO) copying the value of the version property from the detached instance to the attached one. Its just when it does that copy its updating the original value, when it shouldn't be copying at all.

To highlight I have modified the exampleAppSimple to first update the object to make the version value non zero on the attached instance. By doing that I can show that the "original" value of ds2Copy after the merge IS indeed incorrectly set to the value of ds2.version

So I think still merge doesn't work as advertised, and I am not aware of any way to workaround it. Modified example app attached:

exampleAppSimple2.zip

[boardbloke]

I have now checked, and Grails 7.0.0-M5 exhibits the same behavior, Example app attached:

exampleAppGrails700M5.zip

[boardbloke]

Any further thoughts on this @jamesfredley, @jdaugherty ?