On Jul 23, 2010, at 8:56 PM, Doug wrote: > Thanks for your explanations Dan. The new WAL feature sounds great > and I'm > excited to try it. Two questions below: > >> When in WAL mode, clients use file-locks to implement a kind of >> robust (crash-proof) reference counting for each database file. >> When a client disconnects, if it is the only client connected to >> that database file, it automatically runs a checkpoint and >> then deletes the *-wal file. >> > ... >> On the other hand, if the only client connected to a database >> does not disconnect cleanly (i.e. it crashes, the system crashes, >> or the client exits without calling sqlite3_close()), then it >> leaves the *-wal file in place. In this case, when the next >> client connects to the database file it has to read the entire >> *-wal file to reconstruct the wal-index. If the *-wal file is >> large, this might take a while. > > With WAL mode if there is a crash, it seems like the reference > counting > would be messed up from that point on (meaning too high). In that > case, the > *-wal file will always exist, right? It wouldn't affect the database > robustness but I guess it would be a case where the startup > performance > being discussed would be affected. > > Also, is the reference counting per process or per connection?
Well, that was a little bit deceptive, there is actually no explicit reference counting code in user space. SQLite uses file-locks to get the kernel to do it. When a process dies the kernel automatically cleans up any locks held by the process, so the reference count is kept straight even if a crash occurs. Basically each process holds a shared (read) lock on a well known region of the wal-index file. When a process connects, it tries to take an exclusive (write) lock on that same region. If successful, this proves the reference count just went from 0->1. So the process builds a fresh wal-index and downgrades to a shared lock. If it cannot get the exclusive lock there must be some other process already connected to the database. In this case it just grabs a shared lock and trusts that the wal-index has already been built. Beating the various race conditions makes things a bit more complex than the explanation above of course. But that's the gist of it. Dan. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
