SQLite

mode attempts to open and rollback all 16 potential hot journal files.

<p> But, in order to support non-blocking "BEGIN READONLY" transactions, it is
also in some ways more complicated than multi-process mode. "BEGIN READONLY"
support works as follows:

<ul>





  <li> <p>In single-process mode, writers never spill the cache mid-transaction.
    Data is only written to the database as part of committing a transaction.

  <li> <p>As well as writing the contents of overwritten pages out to the journal
    file, a writer in single-process mode also accumulates a list of buffers
    containing the original data for each page overwritten by the current
    transaction in main-memory.

  <li> <p>When a transaction is ready to be committed, a writer obtains a
    transaction-id. Transaction-ids are assigned to writers using a
    monotonically increasing function. The writer then adds all of its "old
    data" buffers to a hash table accessible to all database clients.
    Associated with each hash table entry is the newly assigned transaction-id.
    It then waits (spin-locks) for all "BEGIN READONLY" read-locks to clear on
    all pages that will be written out by the transaction. Following this, it
    commits the transaction as normal (writes out the dirty pages and zeroes
    the journal file header).

  <li> <p>Clients executing "BEGIN READONLY" transactions are not assigned
    a &lt;client-id&gt;. Instead, they are assigned a transaction-id that is 
    either (a) that of the oldest transaction-id belonging to a writer that has
    not yet finished committing, or (b) if there are currently no writers
    committing then the value that will be assigned to the next committer.

  <li> <p>When a "BEGIN READONLY" transaction reads a page, it first checks
    the aforementioned hash table for a suitable entry. A suitable entry
    is one with the right page-number and a transaction-id greater than or
    equal to that of the "BEGIN READONLY" transaction (i.e. one that had not
    finished committing when the BEGIN READONLY transaction started). If such 
    an entry can be found, the client uses the associated data instead of
    reading from the db file. Or, if no such entry is found, the client:
    <ol>
      <li> Increments the number of BEGIN READONLY read-locks on the page.
      <li> Reads the contents of the page from the database file.
      <li> Decrements the number of BEGIN READONLY read-locks on the page.
    </ol>
    <p> The mutex used to protect access to the array of locking slots and
    the shared hash table is relinquished for step 2 above.