No, pessimistic locking works to some extent - I overlooked a detail in the descriptor. However, there are some important questions remaining:

In earlier JBoss versions we used to define container configurations and assigned them to EntityBeans in the jboss.xml. In these configurations we could specify pooling, commit option, interceptors and others. However, this file is ignored in AS7.

In AS7 it seems that we can use the <optimistic-locking> entry in the jbosscmp-jdbc.xml to decide whether or not optimistic locking is to be used. (Right?)

An EntityBean where we add

  <optimistic-locking>

    <version-column/>

    <column-name>ocColumn</column-name>

    <jdbc-type>BIGINT</jdbc-type>

    <sql-type>NUMERIC (38)</sql-type>

  </optimistic-locking>

is controlled optimistically using the version column 'ocColumn'. From the outcomes of our test suites we assume, that the behavior is equivalent to the "Instance Per Transaction CMP 2.x EntityBean" from earlier versions, which means:

  - commit option C

  - use of a per-transaction instance cache

  - sync-on-commit-only = false (include updates in non-PK finders)

When we ommit the <optimistic-locking> entry, we actually see pessimistic locking. But we have no clue about the inner behavior. Think of the following scenario using entity A and B (both pessimistic):

- Process 1: read A, wait 5 seconds, then read B

- Process 2: wait 1 second, read B, wait 2 seconds, then read A

With pessimistic locking this is a textbook application deadlock. In earlier versions this deadlock was detected by JBoss and a org.jboss.util.deadlock.ApplicationDeadlockException was thrown. In AS7 both threads are stuck in:

  java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)

  java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842)

  java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178)

  org.jboss.as.ejb3.tx.OwnableReentrantLock.lock(OwnableReentrantLock.java:86)

  org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:80)

After exactly one hour we see a

javax.ejb.TransactionRolledbackLocalException: No transaction is running

at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$2.processInvocation(EjbExceptionTransformingInterceptorFactories.java:93)

- Does JBoss 7.1 not detect application deadlocks anymore?

- Where is this timeout defined?

Another important question is this: In earlier JBoss versions we used the <row-locking> element in the jbosscmp-jdbc.xml for pessimistic entities where we did not want to wait until an existing lock is gone.

- Is there a way to achieve this behavior on JBoss7 too?

Thanks, Klaus

I went on investigating the pessimistic concurrency for EJB 2.1 EntityBeans and found two more issues - one of them reather serious:

1. Reuse of a PK in the same TA

If I delete an EntityBean with a primary key X and then create it anew in the same TA with the same PK X the following Error log appears:

    16:41:42,980 ERROR [org.jboss.as.ejb3] (EJB default - 10) JBAS014138: Exception releasing entity: java.lang.IllegalStateException:

            JBAS014172: Instance [org.jboss.as.cmp.component.CmpEntityBeanComponentInstance@70dcfe0a] not found in cache

          at org.jboss.as.ejb3.component.entity.entitycache.ReferenceCountingEntityCache.release(ReferenceCountingEntityCache.java:85)

However this does not affect the result of the operation. The creation is successful.

2. Transaction isolation

- Transaction1 reads an EntityBean with PK X and sets the value of the field f1 to "Value1".

- Transaction1 waits for 5 seconds

      - Transaction2 tries to read EntityBean with PK X while Transaction1 is still waiting (holding the lock).

- Transaction1 - after 5 seconds - throws a RuntimeException which should rollback the transaction.

      - Transaction2 now gets hold of the EntityBean with PK X  -  and finds "Value1" in f1 !

This means, TA2 cann see the result of TA1 which was rolled back!

I made a reproducer for both issues. I can post it wherever you like. (Should I file a Jira issue?)

We use pessimistic locking for the creation of gapless number ranges. This issue is a blocker for us.

Klaus