org.hibernate.test.jpa.lock
Class JPALockTest

java.lang.Object
  org.hibernate.testing.junit4.BaseUnitTestCase
      org.hibernate.testing.junit4.BaseCoreFunctionalTestCase
          org.hibernate.test.jpa.AbstractJPATest
              org.hibernate.test.jpa.lock.JPALockTest

public class JPALockTest
extends AbstractJPATest

Tests specifically relating to section 3.3.5.3 [Lock Modes] of the JPA persistence specification (as of the Proposed Final Draft).

Nested Class Summary

Nested classes/interfaces inherited from class org.hibernate.test.jpa.AbstractJPATest

AbstractJPATest.JPAAutoFlushEventListener, AbstractJPATest.JPAFlushEntityEventListener, AbstractJPATest.JPAFlushEventListener, AbstractJPATest.JPAPersistEventListener, AbstractJPATest.JPAPersistOnFlushEventListener

Nested classes/interfaces inherited from class org.hibernate.testing.junit4.BaseCoreFunctionalTestCase

BaseCoreFunctionalTestCase.RollbackWork

Field Summary

Fields inherited from class org.hibernate.testing.junit4.BaseCoreFunctionalTestCase

DIALECT, NO_CLASSES, NO_MAPPINGS, USE_NEW_METADATA_MAPPINGS, VALIDATE_DATA_CLEANUP

Constructor Summary

JPALockTest()

Method Summary

void	testLockModeTypeRead() Test the equivalent of EJB3 LockModeType.READ From the spec: If transaction T1 calls lock(entity, LockModeType.READ) on a versioned object, the entity manager must ensure that neither of the following phenomena can occur: P1 (Dirty read): Transaction T1 modifies a row.
void	testLockModeTypeWrite() Test the equivalent of EJB3 LockModeType.WRITE From the spec: If transaction T1 calls lock(entity, LockModeType.WRITE) on a versioned object, the entity manager must avoid the phenomena P1 and P2 (as with LockModeType.READ) and must also force an update (increment) to the entity's version column.

Methods inherited from class org.hibernate.test.jpa.AbstractJPATest

buildAutoFlushEventListeners, buildFlushEntityEventListeners, buildFlushEventListeners, buildPersisOnFlushEventListeners, buildPersistEventListeners, configure, getCacheConcurrencyStrategy, getMappings, prepareBootstrapRegistryBuilder

Methods inherited from class org.hibernate.testing.junit4.BaseCoreFunctionalTestCase

addMappings, addMappings, afterConfigurationBuilt, afterConfigurationBuilt, afterSessionFactoryBuilt, afterTest, applyCacheSettings, assertAllDataRemoved, beforeTest, buildConfiguration, buildServiceRegistry, cleanupCache, cleanupTest, configuration, constructConfiguration, createSchema, generateBootstrapRegistry, getAnnotatedClasses, getAnnotatedPackages, getBaseForMappings, getDialect, getXmlFiles, onFailure, openSession, openSession, overrideCacheStrategy, prepareBasicRegistryBuilder, prepareTest, readCommittedIsolationMaintained, rebuildSessionFactory, rebuildSessionFactoryOnError, serviceRegistry, sessionFactory

Methods inherited from class org.hibernate.testing.junit4.BaseUnitTestCase

releaseTransactions

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

JPALockTest

public JPALockTest()

Method Detail

testLockModeTypeRead

public void testLockModeTypeRead()

Test the equivalent of EJB3 LockModeType.READ

From the spec:

If transaction T1 calls lock(entity, LockModeType.READ) on a versioned object, the entity manager must ensure that neither of the following phenomena can occur:

• P1 (Dirty read): Transaction T1 modifies a row. Another transaction T2 then reads that row and obtains the modified value, before T1 has committed or rolled back. Transaction T2 eventually commits successfully; it does not matter whether T1 commits or rolls back and whether it does so before or after T2 commits.
• P2 (Non-repeatable read): Transaction T1 reads a row. Another transaction T2 then modifies or deletes that row, before T1 has committed. Both transactions eventually commit successfully.

  This will generally be achieved by the entity manager acquiring a lock on the underlying database row. Any such lock may be obtained immediately (so long as it is retained until commit completes), or the lock may be deferred until commit time (although even then it must be retained until the commit completes). Any implementation that supports repeatable reads in a way that prevents the above phenomena is permissible.

  The persistence implementation is not required to support calling lock(entity, LockMode-Type.READ) on a non-versioned object. When it cannot support such a lock call, it must throw the PersistenceException. When supported, whether for versioned or non-versioned objects, LockMode-Type.READ must always prevent the phenomena P1 and P2. Applications that call lock(entity, LockModeType.READ) on non-versioned objects will not be portable.

  EJB3 LockModeType.READ actually maps to the Hibernate LockMode.OPTIMISTIC

testLockModeTypeWrite

public void testLockModeTypeWrite()

Test the equivalent of EJB3 LockModeType.WRITE

From the spec:

If transaction T1 calls lock(entity, LockModeType.WRITE) on a versioned object, the entity manager must avoid the phenomena P1 and P2 (as with LockModeType.READ) and must also force an update (increment) to the entity's version column. A forced version update may be performed immediately, or may be deferred until a flush or commit. If an entity is removed before a deferred version update was to have been applied, the forced version update is omitted, since the underlying database row no longer exists.

The persistence implementation is not required to support calling lock(entity, LockMode-Type.WRITE) on a non-versioned object. When it cannot support a such lock call, it must throw the PersistenceException. When supported, whether for versioned or non-versioned objects, LockMode-Type.WRITE must always prevent the phenomena P1 and P2. For non-versioned objects, whether or not LockModeType.WRITE has any additional behaviour is vendor-specific. Applications that call lock(entity, LockModeType.WRITE) on non-versioned objects will not be portable.

Due to the requirement that LockModeType.WRITE needs to force a version increment, a new Hibernate LockMode was added to support this behavior: LockMode.FORCE.