On Mar 5, 2009, at 12:10 AM, Tito Ciuro wrote: > Hello, > > On Mar 4, 2009, at 6:06 AM, D. Richard Hipp wrote: > >> See http://www.sqlite.org/atomiccommit.html and especially section >> 9.0 >> "Things That Can Go Wrong" > > Reading the above link, I'm curious about a specific case: 4.2 Hot > Rollback Journals. It states that: > > [...] > 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 rollback journal file present. SQLite > then checks to see if the rollback journal is a "hot journal". > [...] > > SQLite's documentation in http://www.sqlite.org/lockingv3.html states > the following about a shared lock: > > [...] > The database may be read but not written. Any number of processes can > hold SHARED locks at the same time, hence there can be many > simultaneous readers. But no other thread or process is allowed to > write to the database file while one or more SHARED locks are active. > [...] > > So, if when SQLite attempts to access the data file for the first time > (thread T1) and obtains a shared lock, it seems that there's a window > of opportunity for secondary thread (T2) to obtain another shared > lock. In this case, T1 would not obtain an exclusive lock until T2 has > completed reading. This would potentially leave T2 with damaged/ > inconsistent data. Once T2's shared lock was relinquished, T1 would > proceed to rollback the hot journal. > > Shouldn't the first connection obtain an exclusive lock right away > instead and then perform the testing for the existence of a hot > journal? I'm probably mistaken, but this is what I gather from the > documentation mentioned above.
After obtaining a shared-lock, SQLite tests for the existence of a hot-journal file. The test for a hot-journal file is that the journal file exists and that no other connection holds a RESERVED or PENDING lock on the database file. We know no other process is holding an EXCLUSIVE lock on the database file, since we are holding a SHARED lock. If it determines that there is a hot-journal file in the file system, SQLite obtains an EXCLUSIVE lock on the database file. It does not obtain a RESERVED or PENDING lock first like it does normally, but jumps straight to EXCLUSIVE. If the EXCLUSIVE lock is obtained Ok, roll back the journal file. If not, then release all locks and return SQLITE_BUSY. If the EXCLUSIVE lock cannot be obtained, then some other process must have obtained a SHARED lock. The other process will also try to roll back the hot-journal. By releasing all locks, hopefully we can get out of the other processes way fast enough to allow it to obtain the EXCLUSIVE lock and roll back the journal file. The key is that at no point is it possible for a second process to conclude that the database is valid when there is really a hot-journal file that requires rollback in the file-system. If there are multiple clients all trying to access the database at once then a few operations might return SQLITE_BUSY, but eventually one of the clients will successfully obtain the EXCLUSIVE lock and roll back the hot-journal. Dan. > Regards, > > -- Tito > _______________________________________________ > 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
