When a developer creates operations on an entity they must first determine if that entity supports optimistic locking. Optimistic locking is described in the Cúram Modeling Reference Guide and provides a suitable method of ensuring that transactions are ACID. However there are situations when using optimistic locking can unnecessarily impact on the performance of a transaction. If a record is read and then modified later in the transaction it is unlikely (though not impossible) that the record will have changed underneath the developer. Rather than using the version number it is often more suitable to lock the record when it is read. This means that it is impossible for another transaction to change the record, so there is no need to guard the modify with a version number. However it also means that the possibility of locks and deadlocks increases.
This form of locking is supported in Cúram via an extra parameter which can be passed to any of the standard read operations. This parameter (forUpdate), when set to true, will result in an update lock being taken on the record(s) that are being accessed as part of this query. These locks will not be released until the end of a transaction.