When an entity has been locked within a transaction and later a refresh is invoked upon it this causes EntityManager.getLockMode to return the standard OPTIMISTIC lock mode type (indicating not locked).
A simple project has been included which illustrates this.
, thanks for the update!
after discussing on the hibernate-dev mailing list, we agree that this is a bug.
Good news; thanks for looking into this! Maybe once such changes are live I can convince my various project teams to finally upgrade.
It appears that the original database lock in the first transaction blocks the load from the second transaction. Did you see this behavior as well?
In other words, in your testing, did you actually find that the database lock was released after refreshing, and that a second transaction was able to update the entity?
Yes, the behavior you observed is the behavior I find as well. Refreshing an entity does not release the database locks (I do not believe it's even possible to release a database lock without a rollback/commit). The locking semantics within the actual database transactions are correct - it is just the lock mode within the session/entity manager that is getting out of sync.
, thanks for the feedback!
Waiting on feedback from wrt PR
Going to unschedule this soon...
Fixed in master and 5.2 branches.