Child pages
  • EOF-Using EOF-Optimistic Locking

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Note that this section covers the locking strategy EOF uses at the databases layer as opposed to EOEditingContext locking which happens much higher in the stack. For information on EOEditingContext locking, please see Context and Database Locking.


As an example of how optimistic locking in EOF works, assume you have a Person EO with the PersonID 123, first name "Bob", and last name "Roberts". If you change the first name to "Robert" and saveChanges() on your editing context, you would see the following SQL sent to your database:

Code Block
  UPDATE Person SET FirstName = 'Robert' WHERE PersonID = 123 AND FirstName = 'Bob' AND LastName = 'Roberts'


mmalcolm gave a presentation at O'Reilly's 2002 Mac OS X conference titled "A Lack of Conflicts in EOF, or 'Hey Mom, Someone Overwrote My Data!'" and the slides are available at Removed

Optimistic Locking and Performance

There have been several threads of discussion about the additional database server load with optimistic locking (as the database much verify all of the locked column values prior to an update).


Database benchmarks are never simple, and often don't apply across databases of different vendors, so take these results with a grain of salt. Always profile your application before you make large sacrifices in functionality.

Seeing it Occur

Kieran Kelleher

Here is the easiest way to trigger it.


If you log out the SQL while changing you will see that optimistic locking effects the WHERE part of all the UPDATE statements that are generated.Category:WebObjects