2. More About the Object Relational Model
* Optimistic Locking
<< * Customized Load Methods   |   Back to Main   |   Next >>

View Source
will open in a new window
Optimistic Locking and TIMESTAMP Columns
If you are generating any table that has a TIMESTAMP column, then Qcodo will automatically generate the functionality to perform Optimistic Locking for that object. In this example, the person_with_lock table is defined with a TIMESTAMP column so that we can demonstrate Optimistic Locking.

Optimistic Locking is the loosest form of row- or object-level locking that, in general, works best for database-driven web-based applications. In short, everyone is always allowed to read any row/object. However, on save, you are only allowed to save if your object is considered "fresh". Once your object is "stale", then you locked out from being able to save that stale object. (Note that this is sometimes also called a "mid-air collision".)

Programatically, this is done via TIMESTAMP columns. Remember that TIMESTAMP columns are updated by the database on every UPDATE.

So whenever you Load an object, you also get the latest TIMESTAMP information. On Save, the TIMESTAMP in your object will be checked against the TIMESTAMP in the database. If they match, then the framework knows your data is still fresh, and it will allow the Save. If they do not match, then it is safe to say that the data in the object is now stale, and Qcodo will throw an Optimistic Locking Exception.

Note that the Optimistic Locking constraint can be overridden at any time by simply passing in the optional $blnForceUpdate as true when calling Save.

Object Save and Double Saves on the PersonWithLock Object

Saving a Single Object will perform the save normally

Attempting to save a Two Instances of the Same Object will throw an Optimistic Locking Exception

Using $blnForceUpdate to avoid the Optimistic Locking Exception