Created ticket #884, with patch against latest cvs:
http://www.sqlite.org/cvstrac/tktview?tn=884
Minimal testing done, tested only within sqlite3 shell on Linux. A bit of
a hack. Mainly a RFC.
Quick transcript:
[EMAIL PROTECTED] sqlite]$ ./sqlite3 db
SQLite version 3.0.5
Enter ".help" for instructions
sqlite> begin for read only;
sqlite> create table t (a,b);
SQL error: access permission denied
sqlite> commit;
sqlite> begin ;
sqlite> create table t (a,b);
sqlite> insert into t values (1,2);
sqlite> commit;
sqlite> .dump
BEGIN TRANSACTION;
CREATE TABLE t (a,b);
INSERT INTO "t" VALUES(1, 2);
COMMIT;
sqlite>
Already found first bug:( "DELETE FROM <table>;" doesn't use OpenWrite,
which I updated to enforce the read only nature of a transaction. I'll
need to update OP_Clear and OP_Destroy as well. This could get messy
quickly, hence the implementation is considered a hack:)
Copyright disclaimed, etc.
Christian
On Wed, 1 Sep 2004, Christian Smith wrote:
>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
/ \
