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).
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.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 java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
JPALockTest
public JPALockTest()
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
.
Copyright © 2001-2012 Red Hat, Inc. All Rights Reserved.