Darren Duncan wrote:

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.

Correct.


Q: Would a RESERVED lock be acquired automatically, or alternately be the best thing to get, if someone runs a "SELECT ... FOR UPDATE"?

I suppose. Haven't really thought about it because SQLite does not support 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.

The documentation should say that no other process can hold any lock at the same time as one process is holding an EXCLUSIVE lock.


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.

You misunderstand the purpose of PENDING. A PENDING lock exists in order to prevent other processes from acquiring SHARED locks. No such functionality is needed for SHARED or RESERVED locks.


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.

Non-blocking is the only option. Though you can register a callback to be invoked when a lock fails. See the sqlite_busy_callback() API. The same API (with minor changes) will be available in SQLite 3.0.


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.

Win95/98/ME only supports UNLOCKED and EXCLUSIVE. And Unix only supports POSIX advisory locks which follow a profoundly stupid design. And yet from these humble primitives we are able to construct the locking system described in the document. For details see the code when it comes out on Friday.


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?

ATTACHed database only get locked if needed. They get a SHARED lock if you read from them and an RESERVED lock if you write to them. If you don't use them at all they remain unlocked.


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?

You can think of it that way, yes.


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?

Correct.




-- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to