Locking Behavior

In the case of the iterator, the first time iter.next is executed a group of object references will be fetched from the database (object references are also known as object IDs, or OIDs). The size of the group is normally 51, but it is less for dictionaries with large keys.

The collection is implicitly share locked for the duration of the fetching of the group of OIDs. The lock is released when the group of OIDs is sent to the requesting node. When the group of OIDs is exhausted, another group will be fetched from the database. The collection is locked and unlocked each time another group is fetched.

The foreach instruction implicitly share locks the collection at the start of the iteration and releases the lock when the endforeach instruction is reached.

If the discreteLock option is used with the foreach instruction, the locking aspect of the construct is the same as the iterator; that is, the collection is locked each time a group of OIDs is fetched and it is released when the OIDs are returned.

If the iterator construct is surrounded by beginLoad and endLoad or beginTransaction and commitTransaction instruction pairs, the locking behavior becomes like that of the foreach instruction without the discreteLock option. This is because when in transaction state or load state, all transaction duration locks are held until the next endLoad, commitTransaction, or abortTransaction instruction.

The Dictionary class getIteratorKeys method share locks the collection on each call. If you are in load state or transaction state, the locking may not matter. The Iterator class getCurrentKey and getCurrentKeys methods can be used as an alternative to avoid the locking overhead.