Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep

org.hibernate.test.ejb3.lock
Class EJB3LockTest  view EJB3LockTest download EJB3LockTest.java

java.lang.Object
  extended byjunit.framework.Assert
      extended byjunit.framework.TestCase
          extended byorg.hibernate.test.TestCase
              extended byorg.hibernate.test.ejb3.lock.EJB3LockTest
All Implemented Interfaces:
junit.framework.Test

public class EJB3LockTest
extends org.hibernate.test.TestCase

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


Field Summary
 
Fields inherited from class org.hibernate.test.TestCase
SKIP_LOG
 
Fields inherited from class junit.framework.TestCase
 
Constructor Summary
EJB3LockTest(java.lang.String name)
           
 
Method Summary
protected  void configure(org.hibernate.cfg.Configuration cfg)
           
 java.lang.String getCacheConcurrencyStrategy()
           
protected  java.lang.String[] getMappings()
           
static junit.framework.Test suite()
           
 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.TestCase
afterSessionFactoryBuilt, appliesTo, assertClassAssignability, assertElementTypeAssignability, dialectIsCaseSensitive, dialectSupportsEmptyInList, dropAfterFailure, fullTestName, getBaseForMappings, getCfg, getDialect, getExtraProperties, getSessions, openSession, openSession, overrideCacheStrategy, readCommittedIsolationMaintained, recreateSchema, reportSkip, reportSkip, runTest, setCfg, setUp, sfi
 
Methods inherited from class junit.framework.TestCase
countTestCases, createResult, getName, run, run, runBare, setName, tearDown, toString
 
Methods inherited from class junit.framework.Assert
assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertFalse, assertFalse, assertNotNull, assertNotNull, assertNotSame, assertNotSame, assertNull, assertNull, assertSame, assertSame, assertTrue, assertTrue, fail, fail
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
 

Constructor Detail

EJB3LockTest

public EJB3LockTest(java.lang.String name)
Method Detail

suite

public static junit.framework.Test suite()

getMappings

protected java.lang.String[] getMappings()

getCacheConcurrencyStrategy

public java.lang.String getCacheConcurrencyStrategy()

configure

protected void configure(org.hibernate.cfg.Configuration cfg)

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.

    Odd as it may sound, EJB3 LockModeType.READ actually maps to the Hibernate LockMode.UPGRADE


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>LockMode.FORCE 55 .