'''Intent:''' Maintains a list of objects that are affected by a business transaction and coordinates the writing out of changes and resolution of concurrency problems. 

Google reveals another page on Fowler's site which actually has content: 
http://www.martinfowler.com/eaaCatalog/unitOfWork.html

If I've got it right, a unit of work is to the client what a transaction is to the server, yes? But then, why not just use the same word for both and simply talk about committed vs uncommitted transactions?

It doesn't seem that a unit of work is large. The word 'unit' implies something small. So to aggregate transactions, changesets nested within each other are a better abstraction.

Typically, the unit of work contains an initially empty Write''''''Set. When a change occurs (creating a new version of an existing object) to an object, the new version of the object is entered in the Write''''''Set of the unit of work that pertains to the change. Various strategies (optimistic, pessimistic, etc) govern whether or not a completed unit of work is committed or not and how visible it is across process and/or machine boundaries. The approach I'm most familiar with maintains a Read''''''Set as well as a Write''''''Set. Since each change to an object causes a new version to be created (and therefore a new object id), the object id of an object doubles as a timestamp. When a unit of work is committed, the Write''''''Set is compared to the Read''''''Set. If there is any reference in the Write''''''Set that doesn't match a reference in the Read''''''Set, it means that a new version of the object that is about to be written was encountered during the unit of work, and the unit of work is aborted. This is an optimistic strategy, because it allows multiple processes to change objects so long as the unit of work reads the change (updating the Read''''''Set) before committing. 

----
See also DataMapper

CategoryPattern