Problems in Supporting DB Transactions in an OS TM
 ==================================================

 Mike Stonebraker, 1985


 Theme:  Can a DBMS use a generic Transaction Manager exported by the OS?


 Overview
 --------

   The paper discusses the problems faced when INGRES tried to use
   ROAM, an OS-supported transaction manager.

   ROAM provides concurrency control at page/block level by using
   2 Phase Locking (it holds locks until the transaction ends).
   Recovery is provided by maintaining a log containing pre- and post-
   images of pages written.

   Concurrency control and recovery is transparent to the user (transaction
   process) which simply issues a sequence of reads and writes to pages/blocks.


 Problems faced
 --------------

   - Granularity of locking:

     Page level locking leads to "false sharing" which diminishes concurrency.

     
   - Physical vs logical logging:

     ROAM logs all physical changes to pages/blocks. However, a DB can compress
     such a log by logical logging as it is aware of the semantics of its
     actions. However, there is a tradeoff: during recovery, ROAM would have
     to do less work (simply restore pre-images for rollbacks); DB would
     have to do more work to translate the logical log entries into physical
     updates/rollbacks to blocks.

   - Using semantics for logging and recovery

     The classic example where ROAM fails is the following: during
     updates/deletes of tuples in any table, the catalogs have to be locked
     as they store the tuple-count for every table. This requires a write
     lock on the catalogs page which reduces concurrency to one such
     transaction at a time.  The solution is to allow "event"-logging with
     user-defined functions for adding/deleting/redoing/undoing events (simply
     storing pre- and post- images does not work). This requires considerable
     change to ROAM: Logging and recovery routines now have to invoke user
     defined functions which incorporate semantics.

 Conclusion
 ----------

     A simple transaction manager which supports page-level physical logging
     is clearly not sufficient for DBMS's.  It must provide support for varying
     granularity of locking and logical logging.  More importantly, it must
     allow user defined logging and recovery for certain data which
     incorporate the semantics of data being logged.