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>Clients executing "BEGIN READONLY" transactions are not assigned
    a &lt;client-id&gt;. Instead, they have a transaction-id that is unique
    within the lifetime of the process. Transaction-ids are assigned using a 
    monotonically increasing function.

  <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 to be committed, a writer first obtains a
    transaction-id (in the same way as a BEGIN READONLY client) and 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>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 that
    of the "BEGIN READONLY" transaction (i.e. one added to the hash table 
    <i>after</i> 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.

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.