Index: pages/atomiccommit.in ================================================================== --- pages/atomiccommit.in +++ pages/atomiccommit.in @@ -30,11 +30,11 @@
The information in this article applies only when SQLite is operating in "rollback mode", or in other words when SQLite is not using a [write-ahead log]. SQLite still supports atomic commit when write-ahead logging is enabled, but it accomplishes atomic commit by -a different mechanism from the one describe in this article. See +a different mechanism from the one described in this article. See the [WAL | write-ahead log documentation] for additional information on how SQLite supports atomic commit in that context.
By default, SQLite assumes that an operating system call to write a range of bytes will not damage or alter any bytes outside of that range -even if a power lose or OS crash occurs during that write. We +even if a power loss or OS crash occurs during that write. We call this the "[PSOW | powersafe overwrite]" property. Prior to version 3.7.9, SQLite did not assume powersafe overwrite. But with the standard sector size increasing from 512 to 4096 bytes on most disk drives, it has become necessary to assume powersafe overwrite in order to maintain historical performance levels and so powersafe overwrite is assumed by @@ -224,11 +224,11 @@ another database connection from writing to the database file while we are reading it. This is necessary because if another database connection were writing to the database file at the same time we are reading from the database file, we might read some data before the change and other data after the change. -This would make it appears as if the change made by the other +This would make it appear as if the change made by the other process is not atomic.
Notice that the shared lock is on the operating system disk cache, not on the disk itself. File locks really are just flags within the operating system kernel, @@ -275,11 +275,11 @@ locks from other processes. However, there can only be a single reserved lock on the database file. Hence only a single process can be attempting to write to the database at one time.
-The idea behind a reserved locks is that it signals that +
The idea behind a reserved lock is that it signals that a process intends to modify the database file in the near future but has not yet started to make the modifications. And because the modifications have not yet started, other processes can continue to read from the database. However, no other process should also begin trying to write to the @@ -404,11 +404,11 @@ database changes are written into nonvolatile storage. This is a critical step to ensure that the database will survive a power loss without damage. However, because of the inherent slowness of writing to disk or flash memory, this step together with the rollback journal file flush in section -3.7 above takes up most the time required to complete a +3.7 above takes up most of the time required to complete a transaction commit in SQLite.
After the database changes are all safely on the mass
storage device, the rollback journal file is deleted.
This is the instant where the transaction commits.
If a power failure or system crash occurs prior to this
point, then recovery processes to be described later make
-it appears as if no changes were ever made to the database
+it appear as if no changes were ever made to the database
file. If a power failure or system crash occurs after
the rollback journal is deleted, then it appears as if
all changes have been written to disk. Thus, SQLite gives
the appearance of having made no changes to the database
file or having made the complete set of changes to the
@@ -501,21 +501,23 @@
Suppose the power loss occurred during step 3.10 above, +
Suppose the power loss occurred +during step 3.10 above, while the database changes were being written to disk. After power is restored, the situation might be something like what is shown to the right. We were trying to change three pages of the database file but only one page was successfully written. Another page was partially written and a third page was not written at all.
The rollback journal is complete and intact on disk when the power is restored. This is a key point. The reason for -the flush operation in step 3.7 is to make absolutely sure that +the flush operation in step 3.7 +is to make absolutely sure that all of the rollback journal is safely on nonvolatile storage prior to making any changes to the database file itself.
The first time that any SQLite process attempts to access the database file, it obtains a shared lock as described in -section 3.2 above. But then it notices that there is a +section 3.2 above. +But then it notices that there is a rollback journal file present. SQLite then checks to see if the rollback journal is a "hot journal". A hot journal is a rollback journal that needs to be played back in order to restore the database to a sane state. A hot journal only exists when an earlier process was in the middle of committing @@ -534,11 +537,11 @@
A rollback journal is a "hot" journal if all of the following are true:
Once a process obtains an exclusive lock, it is permitted to write to the database file. It then proceeds to read the original content of pages out of the rollback journal and write -that content back to were it came from in the database file. +that content back to where it came from in the database file. Recall that the header of the rollback journal records the original size of the database file prior to the start of the aborted transaction. SQLite uses this information to truncate the database file back to its original size in cases where the incomplete transaction caused the database to grow. At the @@ -594,12 +597,12 @@ can be deleted.
As in section 3.11, the journal file might be truncated to zero length or its header might be overwritten with zeros as an optimization on systems where -deleting a file is expense. Either way, the journal is no -long hot after this step.
+deleting a file is expensive. Either way, the journal is no +longer hot after this step.SQLite version 3.3.14 adds the concept of "Exclusive Access Mode". In exclusive access mode, SQLite retains the exclusive database lock at the conclusion of each transaction. This prevents -other processes for accessing the database, but in many deployments +other processes from accessing the database, but in many deployments only a single process is using a database so this is not a serious problem. The advantage of exclusive access mode is that disk I/O can be reduced in three ways:
When sector writes are atomic and the page size of a database is the same as a sector size, and when there is a database change that @@ -1280,11 +1283,11 @@
If a crash or power loss does occur and a hot journal is left on the disk, it is essential that the original database file and the hot journal remain on disk with their original names until the database file is opened by another SQLite process and rolled back. -During recovery at step 4.2 SQLite locates +During recovery at step 4.2 SQLite locates the hot journal by looking for a file in the same directory as the database being opened and whose name is derived from the name of the file being opened. If either the original database file or the hot journal have been moved or renamed, then the hot journal will not be seen and the database will not be rolled back.
Index: pages/changes.in ================================================================== --- pages/changes.in +++ pages/changes.in @@ -40,11 +40,11 @@ hd_close_aux hd_enable_main 1 } } -chng {2013-03-12 (3.7.16)} { +chng {2013-03-18 (3.7.16)} {