Hello
I am currently preparing for the Oracle "JPA Expert" exam (1Z0-898 / http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=5001&get_params=p_exam_id:1Z0-898).
The JPA spec / API doc () says
Quote:
void lock(Object entity, LockModeType lockMode)
Lock an entity instance that is contained in the persistence context with the specified lock mode type.
(https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManager.html#lock-java.lang.Object-javax.persistence.LockModeType-)
and
Quote:
void refresh(Object entity, LockModeType lockMode)
Refresh the state of the instance from the database, overwriting changes made to the entity, if any, and lock it with respect to given lock mode type.
(https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManager.html#refresh-java.lang.Object-javax.persistence.LockModeType-)
Hence, the following 2 code snippets should leave
m in the same state, i.e. optimistically read-locked:
Code:
Member m = em.find(Member.class, 1L);
em.lock(m, LockModeType.OPTIMISTIC);
Code:
Member m = em.find(Member.class, 1L);
em.refresh(m, LockModeType.OPTIMISTIC);
But, it turns out that hibernate does not respect the OPTIMISTIC read lock if refresh(m, OPTIMISTIC) is used. I.e. if the entity is concurrently modified in another transaction after refresh(m, OPTIMISTIC) was called, the transaction that called refresh() is
not rolled back at commit time, as it should (IMHO) and as, for example, EclipseLink does (verified).
What are your opinions on this? From my point of view it is a bug, but I do not want to create an issue in JIRA before some more experienced users or a developer can confirm this view.
Cheers
Patrick
Login
FAQ
Search