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
Wildfly 10, oracle db
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 ?
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.