The first alpha release of SQLite version 3.0 will occur in less than 7 days. In preparation for that release, a document describing the new file locking mechanism has be prepared and placed on the website. http://www.sqlite.org/lockingv3.html Readers who are so inclined are encouraged to read this document carefully and try to poke holes in the logic of the new locking mechanism. Once the code is published next week, you are further encouraged to try to poke holes in the code itself. Readers are encouraged to be merciless in their criticism of the new locking scheme. Intense, unrestricted peer review is needed in order to make SQLite version 3 a solid product. Thank you for your help.
Okay, some comments or questions ...
3.0 Locking
Q: Is the set of [RESERVED, PENDING, EXCLUSIVE] mutually exclusive such that exactly one lock of exactly one of those can be held at once? That is, if one process/thread holds one of any of those, then others are forbidden from acquiring any one of those? If so, then I see these 3 are different from each other only in how or whether they allow concurrent SHARED locks.
Q: Would a RESERVED lock be acquired automatically, or alternately be the best thing to get, if someone runs a "SELECT ... FOR UPDATE"?
Q: It looks like PENDING only describes the temporary state of a process that requested an EXCLUSIVE lock, but then has to wait (blocked or non-blocked) until the EXCLUSIVE lock is granted. Correct? But if so, then PENDING locks exist at the same time as EXCLUSIVE, while the EXCLUSIVE description says no other locks exist at the same time.
Q: The OS layer doesn't track PENDING locks, given that they seem to be unborn EXCLUSIVE locks. In my mind, PENDING should not even be considered a lock state like UNLOCKED|SHARED|RESERVED|EXCLUSIVE are. Or alternately, I think you should add 2 more states that represent unborn SHARED or RESERVED; those 2 new states refer to what state the process/thread is in while it is waiting to acquire a SHARED or RESERVED lock (whether blocked or non-blocked), just as PENDING is a wait state for EXCLUSIVE. So you should either have 4 or 7 official states.
Q: No matter what kind of lock is requested, do you provide both blocking and non-blocking options for what happens to the process until the lock is granted? I think both should be provided, or all non-blocking if only one option is given.
Q: Given that SQLite uses the operating system's built-in locking mechanisms, how is RESERVED implemented? I have only known the operating system to support UNLOCKED, SHARED, EXCLUSIVE. Mind you, that is just because it is all I have used on plain files, or all I have seen documented.
4.0 The Rollback Journal
Q: If you ATTACH a database to the one you currently have open, then is that database always given the same lock status as the main database, or can it be different? For example, if you have EXCLUSIVE on the main, will attached also be EXCLUSIVE? Or can you attach a database SHARED, such as if you just want to read from it while updating the main?
4.1 Dealing with hot journals
Q: Is this saying that one process/thread can acquire multiple locks at once, or does your language "acquire" and "drop" mean to change the single existing lock from one type to another? Eg: drop exclusive means switch to shared?
5.0 Writing to a database file
Q: It appears from this section that RESERVED locks are the prepubescent form of an EXCLUSIVE lock; they are conceptually the same as the early part of the life of an EXCLUSIVE lock, and exist as an optimization meant to cut down on the amount of time that a process actually does have exclusive file access; it will actually become exclusive as late as possible, such as when a commit is to happen or the change cache fills. Correct?
... in the end, all these questions may just relate to documentation clarity.
In general, the documentation looks good. Though I had to read to the end to understand some issues that were raised earlier on.
In general, the current structure of locking and transactions looks great, as I understand it. I may have further comments/questions after the above questions are answered.
-- Darren Duncan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
