|
|
|
The FairCom database supports optimistic locking in all APIs: JSON DB, SQL, CTDB, and ISAM. Use optimistic locking for maximum scalability and performance. Optimistic locking allows an application to read a record without locking a record. This feature improves application performance as concurrent users increase.
Optimistic locking requires a changeid field to be in a table. This field identifies when a record changes. This field is typically named changeid. You may assign the changeid attribute to any field. You may designate only one field in a table as a changeid field.
When a record is inserted or updated, the server sets the changeid field to the current transaction number. The value of the changeid identifies which transaction changed a record. Each change to a record is guaranteed to have a new transaction number. Thus, the value of the changeid field changes with each update to a record.
When an application updates a record, it includes the changeid field and sets it to the value it previously read. The server checks the value of the changeid field. If the value in the record matches the value in the update, the record has not changed, and the server applies the update. If the changeid value in the record does not match, another user has changed the record, and the server returns an appropriate error.
When an application wants to force an update without change protection, it omits the changeid field from the update or assigns NULL to the changeid field. The server unconditionally updates the record without checking for changes made by other users.
Optimistic locking does not conflict with pessimistic locking because the server always returns an error when another user has put a read or write lock on the record.
LIMITATIONS: This feature is only supported in client/server mode for the following reasons:
See also
addChangeIDfield(), delChangeIDfield(), getChangeIDfieldNumber(), getChangeIDheaderValue(),
