> "There are four levels to the shared-cache locking model: transaction > level locking, table level locking, cache level locking, and schema > level locking. They are described in the following three sub-sections."
This would be a bad way of documenting this because "cache level locking" works on a completely different level than transaction, table or schema level locking. The exclusive mutex is taken inside one call to sqlite3_step() and released upon exit. But all other "locks" have "meta-level" notion and work between calls to sqlite3_*() functions. Pavel On Mon, Aug 13, 2012 at 6:45 AM, Boris Kolpackov <bo...@codesynthesis.com> wrote: > Hi Richard, > > Richard Hipp <d...@sqlite.org> writes: > >> In shared-cache mode, SQLite acquires a mutex on the shared cache, thus >> serializing access. > > Oh, that's quite a surprise. I would have never said that something > like this is going on just by reading the documentation page on shared > cache: > > http://www.sqlite.org/sharedcache.html > > Specifically, quoting Section 2.2, "Table Level Locking": > > "When two or more connections use a shared-cache, locks are used to > serialize concurrent access attempts on a per-table basis. Tables > support two types of locks, "read-locks" and "write-locks". Locks > are granted to connections - at any one time, each database connection > has either a read-lock, write-lock or no lock on each database table. > > At any one time, a single table may have any number of active read-locks > or a single active write lock. To read data [from] a table, a connection > must first obtain a read-lock. To write to a table, a connection must > obtain a write-lock on that table." > > From this I at the time concluded that there could be multiple connections > reading from a table concurrently. But it appears I was wrong. > > Perhaps this page should be updated to reflect this. Specifically, the > last paragraph in Section 2.0: > > "There are three levels to the shared-cache locking model, transaction > level locking, table level locking and schema level locking. They are > described in the following three sub-sections." > > Should probably read something along these lines: > > "There are four levels to the shared-cache locking model: transaction > level locking, table level locking, cache level locking, and schema > level locking. They are described in the following three sub-sections." > > Then a new section should be inserted between 2.2 and 2.3 that reads > along these lines: > > "2.3 Cache Level Locking > > When a connection needs to access (read or write) data from a table, > it must acquire an exclusive mutex on the shared cache. In particular, > this means that in the shared cache mode actual access to the database > pages, regardless of whether for reading or writing, is always serialized." > > If you find it suitable, feel free to use this to update the documentation. > > Boris > -- > Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog > Compiler-based ORM system for C++ http://codesynthesis.com/products/odb > Open-source XML data binding for C++ http://codesynthesis.com/products/xsd > XML data binding for embedded systems http://codesynthesis.com/products/xsde > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
