I have just realized that the following idea can be easily and efficiently implemented.

A CRC is an object that produces objects somewhat like record collections. A CRC holds the only key to a real RC called the "underlying RC". A CRC will produce a key to a TRC that behaves much like an RC. In fact it behaves much like the underlying RC. Upon a TRC's creation its state is that of the underlying RC. The holder of a TRC will observe no changes except those produced by calls on that TRC.

The TRC obeys two new operations: "commit" and "abort" after which the TRC disappears. A TRC also occasionally disappears under largely unpredictable circumstances.

The net effect of all of this is that a TRC appears to be a RC to which no one else holds a key.

The CRC will produce several of these TRC's and they can be active at once. When a commit operations is done to a TRC, modifications that had been made to that TRC are instantaneously made to the underlying RC. When an abort operation is made, there are no effects on RC.

A commit operation succeeds only when the records read via that TRC are not due to be modified by other active TRC's. If such a situation prevents success, the TRC deletes itself {and perhaps the TRC holder!}.

A side effect of all of this stuff may be a journalized record of the committed operations. These journal records include the values of the records read or hashes thereof. Such journal entries may be safely replayed against a record collection in the state it held at the beginning of the journal. If some journal entries are discovered to have corrupted the data base {RC} those entries may be nullified. If this nullification causes other journalized transactions to fail {changes read values} this fact can be made clear to the data base administrator.

I imagine the first implementation of this to be one big PL/I program. It will not need to hold many keys. It may be thought of as providing a cache to the RC. Records read and written by extant TRC's are all held in the storage of the program. in no cases will there be more calls on the RC than if the TRC holders held RC and sometimes less.

The CRC will require "victim determination" logic. It might be based on someone's estimate of the probability of commit vs abort of a conflicting transaction.

The following disciplines are removed from application code and centralized in application independent system code:
Locking logic

Deadlock sensing and victim determination

Journalizing to limit data base damage by buggy transaction code.

Application logic is presented with virtual exclusive access to the data base and locking logic is thus removed from application code.

Testing new transaction code

Weakened access may be provided in order to test new transaction code. This weaker access disables commit. Instead the attempted data base modifications are made available for evaluation by the tester.

Catastrophe Service
In case of catastrophe the journalized transactions may be examined by a general program and those committed by less trusted software may be examined and their effects expunged if desired. This may lead, however, to conflict with subsequent transactions that depended on the effects of the expunged transaction. These subsequent transactions can be identified and brought explicitly to the attention of the data base administrator. Knowledge of the nature of the subsequent conflicting transactions may allow the substitution of alternate transactions equivalent to the original.