using OPTIMISTIC_FORCE_INCREMENT does not increment the version on flush()

Description

In my project I use Wildfly 10 and do the following :

the problem is that the version is not incremented on flush but on JTA transaction commit - which means that my dto doesn't have correct version information which is a major problem for me.

the same issue is also mentioned here: https://stackoverflow.com/questions/17785963/different-behavior-for-optimistic-force-increment-in-hibernate-4-2-vs-3-6

Environment

Wildfly 10, oracle db

Activity

Show:
AdamK
April 13, 2018, 1:17 PM

Has anyone even looked at it ? Why should users even try to submit bugs (with a test case) if they are not read at all ?

Koen Serneels
January 28, 2019, 1:51 PM
Edited

We have the same issue. We need to send version information back to the client. We need to obtain this information before the transaction ends. As we do not know beforehand which entities might have incremented versions (either explicitly by forcing an oplock somewhere or implicitly because data was added) we issue an explicit flush before obtaining the updated version information. However, this does not seem to work on newer Hibernate versions.

This is a real 'pain', it falls in the same category as getting an autoincrement or identity value without having to re-read the data (which is solved by JDBC's RETURN_GENERATED_KEYS). Ie. besides obtaining the assigned identity before tx end we also need to obtain version information and are relying on something like 'flush' unless a better alternative is available.

Assignee

Unassigned

Reporter

AdamK

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Affects versions

Priority

Critical
Configure