0 Replies Latest reply on Dec 5, 2006 3:09 PM by Dennis Angelo

    Transaction Isolation in Embeddable EJB3

    Dennis Angelo Newbie

      I'm not sure if this is the right place to post this but I have a question about the Embeddable EJB3 Container and setting the datasource's Transaction Isolation Level:


      Basically, I am trying to test that when we read a record from a database that we have a READ_LOCK on it by setting the Transaction Isolation level to REPEATABLE_READ. Here is what I'm doing in the test:

      1) I have a Thread that starts a new transaction and obtains a read lock on a database record.
      a) The record is created if it does not yet exists (by calling an EJB with REQUIRES_NEW and inserts that record.
      b) The record is then fetched to obtain a readlock.


      2) While holding that readlock, I have another thread that starts a new transaction and tries to update the locked record.

      3) The test is basically to check that the updating thread blocks and waits for the locking thread to release the lock before updating the record.



      I have successfully ran the test in JBOSS Application Server 4.0.4 but on the EmbeddableEJB3 container here is what happens:

      1) If I don't have the transaction isolation level set to the datasource, the test fails because the database has a READ_COMMITTED (this is the expected behaviour)

      2) If I set the transaction isolation level to REPEATABLE_READ, on the first instance where it tries to insert the record to lock because it doesn't exists yet, my test just hangs and goes into a deadlock situation.

      This is last entry I get from the logs and I noticed that it doesn't seem to be commiting the transactions began:

      4328 DEBUG com.orchestral.component.repository.core.persistence.PersistenceStateManager - PersistenceState was successfully rebuilt.
      4328 DEBUG com.orchestral.component.repository.core.persistence.PersistenceStateManager - Initial PersistenceState sucessfully initialised.
      4422 TRACE org.jboss.tm.TxManager - began tx: TransactionImpl:XidImpl[FormatId=257, GlobalId=null:1165349215672/1, BranchQual=null:1165349215672, localId=0:1]
      4438 INFO com.orchestral.component.repository.core.persistence.domain.metadata.DocumentStorageMetaDataTest - Locking Thread starting...
      4438 INFO com.orchestral.component.repository.core.persistence.domain.metadata.DocumentStorageMetaDataTest - Locking Thread -- Retrieving the CoreMetaDataRepositoryBean/local...
      4438 INFO com.orchestral.component.repository.core.persistence.domain.metadata.DocumentStorageMetaDataTest - Locking Thread -- Obtaining the lock for the metadata...
      4438 DEBUG com.orchestral.component.repository.core.ejb.impl.CoreMetaDataRepositoryBean - Retrieving the storage metadata map...
      4531 DEBUG com.orchestral.component.repository.core.ejb.impl.CoreMetaDataRepositoryBean - Obtaining a read lock for Storage metadata with id '9aa74314-9d28-4d6f-bb10-c86966bde8a2'...
      4844 TRACE org.jboss.tm.TxManager - suspended tx: TransactionImpl:XidImpl[FormatId=257, GlobalId=null:1165349215672/1, BranchQual=null:1165349215672, localId=0:1]
      4844 TRACE org.jboss.tm.TxManager - began tx: TransactionImpl:XidImpl[FormatId=257, GlobalId=null:1165349215672/2, BranchQual=null:1165349215672, localId=0:2]
      4844 DEBUG com.orchestral.component.repository.core.ejb.impl.CoreMetaDataRepositoryBean - Creating a new StorageMetaData for item with id '9aa74314-9d28-4d6f-bb10-c86966bde8a2'.
      4860 TRACE org.jboss.tm.TxManager - suspended tx: TransactionImpl:XidImpl[FormatId=257, GlobalId=null:1165349215672/2, BranchQual=null:1165349215672, localId=0:2]
      4860 TRACE org.jboss.tm.TxManager - began tx: TransactionImpl:XidImpl[FormatId=257, GlobalId=null:1165349215672/3, BranchQual=null:1165349215672, localId=0:3]