Locking

Locking policies

Container uses locking policy to acquire a lock to an instance. A lock can be exclusive or non-exclusive. In case of exclusive lock, only one thread/transaction (the thread/transaction that owns the instance lock) can access the instance. In case of non-exclusive lock, an instance can be accessed concurrently by different threads/transactions.

When a client accesses an instance in a transaction, a lock is acquired when the transaction first accesses the instance and released when the transaction commits or rolls back.

When a client accesses an instance w/o transaction, a lock is acquired (unless the container was configured as reentrant in ejb-jar.xml) for the duration of the method invocation.

Locking policy implements org.jboss.ejb.BeanLock interface.

• Pessimistic locking policy is implemented in org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock. With this policy a client will acquire an exclusive lock to the instance.

• No-lock locking policy is implemented in org.jboss.ejb.plugins.lock.NoLock. This policy acquires a non-exclusive lock allowing concurrent clients to access the same instance simultaneously.

A container can be configured to use a specific locking policy implementation with <locking-policy> element in jboss.xml.

      <container-configuration>
         <container-name>Standard CMP 2.x EntityBean</container-name>
...
         <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
...
      </container-configuration>

Note, locking and caching are tightly coupled. Please, read about caching before changing the default locking policy.

Optimistic locking

This topic is a bit confusing. Therefore, it is covered separately.

Optimistic locking is not a locking policy in terms of locking policies described above, i.e. it's not an implementation of org.jboss.ejb.BeanLock. And, unlike the locking policies described above, optimistic locking is configured in the jbosscmp-jdbc.xml.

Let's think of optimistic locking as a feature of JBossCMP, as a functionality that adds some columns, that represent a version of the data, to the WHERE clause of the SQL UPDATE statement.

Optimistic locking implementation is not tied to any specific locking policy (org.jboss.ejb.BeanLock) implementation nor it is tied to a commit option or caching configuration, i.e. it can be used with any locking policy and commit option (since JBoss-3.2.2).

Therefore, such verbal nonsense like 'container with pessimistic locking policy configured with CMP optimistic locking' might make sense in some clustered deployments.

Optimistic locking strategies

A strategy is what defines which columns should be added to the WHERE clause of the SQL UPDATE statement. Optimistic locking is configured with the <optimistic-locking> element in jbosscmp-jdbc.xml. Please, check the jbosscmp-jdbc_3_2.dtd in the jboss-x.x/docs/dtd for the structure of this element.

• group-name strategy adds fields from the load-group with the same name.

• modified-strategy adds all the fields that were modified in the current transaction.

• read-strategy adds all the fields that were read and/or modified in the current transaction.

• version-column adds a numeric version column. An application developer can choose an existing CMP field to be a version field. Otherwise, the container will add a hidden CMP field to the entity. In either case the container will increase the value of version field by one after each update.

• timestamp-column adds a timestamp version column. As in case of numeric version-column, this field can be one of the CMP fields defined by the application developer or a hidden one added by the container. On each update, the container will update the value of this field to the current time.

• key-generator-factory adds a version column of a specific type. Like in case of numeric version-column, it can be one of the CMP fields defined by the application developer or a hidden one added by the container. On each update, the container will call the key generator to generate the next key which will be used as the version. In 3.2.x, at the moment there is only string-based UUID key generator available by default, in 4.x there are UUID and HiLo.

Related

• Common Mistakes