<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="innodb-transaction-model">
      </a>
      17.7.2 InnoDB Transaction Model
     </h3>
    </div>
   </div>
  </div>
  <div class="toc">
   <dl class="toc">
    <dt>
     <span class="section">
      <a href="innodb-transaction-isolation-levels.html">
       17.7.2.1 Transaction Isolation Levels
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="innodb-autocommit-commit-rollback.html">
       17.7.2.2 autocommit, Commit, and Rollback
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="innodb-consistent-read.html">
       17.7.2.3 Consistent Nonlocking Reads
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="innodb-locking-reads.html">
       17.7.2.4 Locking Reads
      </a>
     </span>
    </dt>
   </dl>
  </div>
  <a class="indexterm" name="idm46045164410880">
  </a>
  <p>
   The
   <code class="literal">
    InnoDB
   </code>
   transaction model aims to combine
      the best properties of a
   <a class="link" href="glossary.html#glos_mvcc" title="MVCC">
    multi-versioning
   </a>
   database with
      traditional two-phase locking.
   <code class="literal">
    InnoDB
   </code>
   performs
      locking at the row level and runs queries as nonlocking
   <a class="link" href="glossary.html#glos_consistent_read" title="consistent read">
    consistent reads
   </a>
   by
      default, in the style of Oracle. The lock information in
   <code class="literal">
    InnoDB
   </code>
   is stored space-efficiently so that lock
      escalation is not needed. Typically, several users are permitted
      to lock every row in
   <code class="literal">
    InnoDB
   </code>
   tables, or any
      random subset of the rows, without causing
   <code class="literal">
    InnoDB
   </code>
   memory exhaustion.
  </p>
 </div>
 <br/>
</div>
