OK, how about this suggestion.
Add a new "BEGIN [TRANSACTION] FOR READONLY" statement, which begins the
transaction with a read lock only and doesn't allow the transaction to
even try to promote to a write lock.
Then, the default behaviour for (default) non-readonly transactions is the
same as 2.8.x, ie. only one writer. The second thread beginning a new
writeable transaction blocks immediately. The benefits of concurrent
readers will not be lost if using auto-transactions or the new read-only
transactions.
No rollback. Consistent busy behaviour. Job's a good'un.
Christian
On Wed, 1 Sep 2004, Miguel Angel Latorre wrote:
>I agree.
>Applications shouldn't worry about locking and timeouts. That would be the
>job for the db core engine, returning as few (none ideally) busy status code
>as possible.
>
>Also, it is not always possible to decide which thread is better to rollback
>since no info is provided about the status of what it is performing (commit,
>update, etc).
>
>----- Original Message -----
>From: "Rob Groves" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Wednesday, September 01, 2004 12:34 AM
>Subject: RE: [sqlite] Locking in 3.0.5
>
>
>> >>So, Rob, are you go to tell us if you think the change
>> >>is an improvement or not?
>>
>> It seems that with either of the new schemes, when using
>> sqlite3_busy_timeout() one thread is going to timeout sooner
>> or later. That being the case I prefer the new version on
>> efficiency grounds.
>>
>> Being a lazy programmer, I like the behaviour of 2.8.15
>> where both threads can get to complete their update, timeouts
>> allowing. This is behaviour that I am also used to with
>> MS SQL Server.
>>
>> I agree with you that many programmers (myself included)
>> don't want to have to worry about this stuff too much
>> when using SQLite.
>>
>> Rob.
>>
>
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
