Using a Lock Protocol

Executing transactions concurrently can adversely affect the integrity of Repository data if a locking protocol is not used. For example, consider two concurrently executing transactions that both increment an integer property of a Repository object. This property represents a sequential counter.

1. Transaction A reads the value of the property. The current value is six.
   
   
2. Transaction B reads the same current value of the property.
   
   
3. Transaction A increments the retrieved property value by one, and writes it back to the Repository database. The value in the database is now seven.
   
   
4. Transaction B increments its copy of the retrieved property value by one and writes it back to the Repository database. The value in the database is still seven. It should be eight.

To avoid this problem, use the Lock method in concurrently executing transactions to serialize access to a Repository item. The Lock method sets an exclusive lock on the item, and refreshes any unchanged cache data for the item. The lock is effective across processes and across computers. If the Repository item is already locked, the lock request waits until the lock becomes available. The item is unlocked when the transaction is ended, either by the Abort method or by the final invocation of the Commit method for the transaction.

By invoking the Lock method, the caller has exclusive access to a Repository item, as long as all other concurrently executing transactions also obtain a lock on that Repository item before updating it.

Caution   Calling the Lock method on a Repository item only prevents other transactions from executing the Lock method on the Repository item. It does not block other transactions that are not using the locking protocol from changing the Repository item.