Comparison
Optimistic lockingvsUnit of work
Optimistic locking
you read the row with its version, write it back only if the version has not changed, and retry the whole thing if it has.
Detecting conflicts at write time by checking that the record has not changed since you read it, usually via a version or timestamp column. There is no lock held, so readers never block and there is no deadlock risk. It works well when conflicts are rare, and degrades badly on hot rows where retries pile up.
Full entry →Unit of work
you changed four objects and called save once, and it worked out the order the writes had to happen in.
An object that tracks everything changed during a business transaction and coordinates writing it out, including ordering and concurrency checks. It is what a session or context in an ORM is, and it is why calling save on one object can produce eight statements. Its two consistent surprises are the flush that happens earlier than you expected, and the fact that a long-lived unit of work is a long-lived pile of tracked state.
Full entry →