On Fri, 11 Jun 2004, D. Richard Hipp wrote:
>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
>
I have a question about the BEGIN and locking.
"Note that the BEGIN command does not acquire any locks on the database.
After a BEGIN command, a SHARED lock will be acquired when the first
SELECT statement is executed. A RESERVED lock will be acquired when the
first INSERT, UPDATE, or DELETE statement is executed."
Surely, after a BEGIN is executed, the database should be considered a
current snapshot, and no subsequent changes should be visible in this
transaction.
However, if connection A executes a BEGIN, then is preempted by connection
B (perhaps in a different process) which updates the database, by the time
connection A is queried, the database will have changed between the BEGIN
and the first statement.
I'd expect the transaction boundry to begin with the BEGIN statement, not
wait until the first command.
Other than that minor query, it looks good.
Another suggestion I might add, how about maintaining a transaction ID of
the last transaction committed? That would allow connections to maintain
their cache between transactions using the following rules:
- Cache is valid if:
- Last transaction ID is unchanged from the data in the cache.
- Last transaction ID is the same as our last write.
- Else, the cache is invalid.
The transaction ID will then be simply incremented for every write
transaction.
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
