As introduced in “Locking”, the Enterprise Object technology supports different locking strategies to deal with the problem of update conflicts. In multi-user database applications in which many users have write access, there is a possibility that multiple users may view and edit the same record concurrently. A good locking strategy can help you avoid problems if this situation arises.
The default locking strategy used by Enterprise Objects is optimistic locking. With this strategy, update conflicts aren’t detected until users try to save an object’s changes to the data store. At that point, Enterprise Objects checks the database row to see if it’s changed since the object being edited was fetched. If the row has been changed, the save operation is rolled back and an optimistic locking exception is thrown.
Enterprise Objects determines that a database row has changed since its corresponding enterprise object was fetched using a technique called snapshotting. When Enterprise Objects fetches an object from the data store, it records a snapshot of the state of the corresponding database row. When changes to an object are saved to the database, the snapshot is compared with the corresponding database row to ensure that the row data hasn’t changed since the object was last fetched.
Enterprise Objects creates snapshots based on the attributes
that are selected for locking. The general rule is that only attributes
that are guaranteed to contain a small amount of easily parseable
data should be selected for locking. For example, an attribute with external
type object, blob,
or clob should never
be selected for locking (except in very rare cases).