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. Regards, -- Tito _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
