Per object possibilities:

1) Lock acquired, version id matches

2) No lock, but version id matches

3) Version id doesn't match

4) Not here

Response to machine running transaction

A) DISAGREE (if we ever see at least 1 #3)

B) AGREE (all #1)

C) AGREE BUT MISSING OBJECTS (mixture of #1 and #4 - no #2 or #3) -
return list of oid's for missing objects (need to build list)

D) SOFT ABORT (need #2, could have #1, #4, can't have #3) - make sure
there are no #3's

Machine running transaction

I) ABORT (Any A's) (rerun computation, clear out transaction records, etc...)

II) COMMIT (All B's)

III) ABORT BUT RETRY COMMIT (don't rerun computation) (Need D, can
have B's, can have C', no A's)

IV) ABORT BUT RETRY COMMIT WITH RELOCATING (don't rerun computation,
but relookup all missing objects) (Need C, can have B's, no A's, no
D's)


Other machine involved in transaction

I) COMMIT - commit object into store

II) ABORT - unlock objects, free transaction resources

III) Transaction machine unreachable...

	If any machine in transaction has seen COMMIT, all COMMIT
(Need to communicate this information in advanced of deciding
COMMIT/ABORT)

	If no one has seen COMMIT, all ABORT