Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Add a new failure scenario to the howtocorrupt.html document. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
115b99a5d13a54b732165e04b4f24abb |
| User & Date: | drh 2011-04-12 18:46:13 |
Context
|
2011-04-12
| ||
| 19:31 | Fix typos in the howtocorrupt.html document. (check-in: ee071c325f user: drh tags: trunk) | |
| 18:46 | Add a new failure scenario to the howtocorrupt.html document. (check-in: 115b99a5d1 user: drh tags: trunk) | |
| 18:17 | Add the "How To Corrupt And SQLite Database" document. (check-in: bc040b36db user: drh tags: trunk) | |
Changes
Changes to pages/howtocorrupt.in.
109 110 111 112 113 114 115 116 117 118 119 120 121 122 |
database at the same time, resulting in database corruption.</p> <p>Note that it is perfectly safe for two or more threads to access the same SQLite database file using the SQLite library. The unix drivers for SQLite know about the POSIX advisory locking quirks and work around them. This problem only arises when a thread tries to bypass the SQLite library and read the database file directly.</p> <h3>2.3 Two processes using different locking protocols</h3> <p>The default locking mechanism used by SQLite on unix platforms is POSIX advisory locking, but there are other options. By selecting an alternative [sqlite3_vfs] using the [sqlite3_open_v2()] interface, an application can make use of other locking protocols that might be more |
> > > > > > > > > > > > > > > > > > > > > > > > |
109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 |
database at the same time, resulting in database corruption.</p> <p>Note that it is perfectly safe for two or more threads to access the same SQLite database file using the SQLite library. The unix drivers for SQLite know about the POSIX advisory locking quirks and work around them. This problem only arises when a thread tries to bypass the SQLite library and read the database file directly.</p> <h4>2.2.1 Multiple copies of SQLite linked into the same application</h4> <p>As pointed out in the previous paragraph, SQLite takes steps to work around the quirks of POSIX advisory locking. Part of that work-around involves keeping a global list (mutex protected) of open SQLite database files. But, if multiple copies of SQLite are linked into the same application, then there will be multiple instances of this global list. Database connections opened using one copy of the SQLite library will be unaware of database connections opened using the other copy, and will be unable to work around the POSIX advisory locking quirks. A <tt>close()</tt> operation on one connection might unknowningly clear the locks on a different database connection, leading to database corruption.</p> <p>The scenario above sounds far-fetched. But the SQLite developers are aware of at least one commercial product that was release with exactly this bug. The vendor came to the SQLite developers seeking help in tracking down some infrequent database corruption issues they were seeing on Linux and Mac. The problem was eventually traced to the fact that the appliation was linking against two separate copies of SQLite. The solution was to change the application build procedures to link against just one copy of SQLite instead of two.</p> <h3>2.3 Two processes using different locking protocols</h3> <p>The default locking mechanism used by SQLite on unix platforms is POSIX advisory locking, but there are other options. By selecting an alternative [sqlite3_vfs] using the [sqlite3_open_v2()] interface, an application can make use of other locking protocols that might be more |