Re: [sqlite] Version 3.0.6 (beta) Was: [sqlite] Locking in 3.0.5

2004-09-02 Thread D. Richard Hipp
[EMAIL PROTECTED] wrote: In a message dated 9/2/2004 1:02:17 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Version 3.0.6 is on the website now. Dr. Hipp, Thanks for moving so fast, I will pull and test. A question, is there an easy way to corrupt a database for testing purposes? s

Re: [sqlite] Version 3.0.6 (beta) Was: [sqlite] Locking in 3.0.5

2004-09-02 Thread WeiChin3
In a message dated 9/2/2004 1:02:17 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Version 3.0.6 is on the website now. Dr. Hipp, Thanks for moving so fast, I will pull and test. A question, is there an easy way to corrupt a database for testing purposes? such as change some byte

[sqlite] Version 3.0.6 (beta) Was: [sqlite] Locking in 3.0.5

2004-09-02 Thread D. Richard Hipp
Darren Duncan wrote: At 6:06 PM -0400 9/1/04, D. Richard Hipp wrote: A subtle bug has been uncovered I am assuming, then, that the next release of SQLite will also officially be beta status, Correct. Version 3.0.6 is on the website now. Hopefully I will be able to release 3.0.7 (stable) in

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Darren Duncan
At 6:06 PM -0400 9/1/04, D. Richard Hipp wrote: I fear that your patch has been overcome by events. A subtle bug has been uncovered in another area of locking which is going to require reworking large sections of the commit/rollback logic. It is very doubtful that your patch will survive this rewo

[sqlite] PATCH Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Christian Smith
On Wed, 1 Sep 2004, D. Richard Hipp wrote: >Christian Smith wrote: >> Created ticket #884, with patch against latest cvs: >> http://www.sqlite.org/cvstrac/tktview?tn=884 >> > >I fear that your patch has been overcome by events. >A subtle bug has been uncovered in another area >of locking which is

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread D. Richard Hipp
Christian Smith wrote: Created ticket #884, with patch against latest cvs: http://www.sqlite.org/cvstrac/tktview?tn=884 I fear that your patch has been overcome by events. A subtle bug has been uncovered in another area of locking which is going to require reworking large sections of the commit/rol

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Christian Smith
rovided 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: [sql

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Derrell . Lipman
"Wei Chin" <[EMAIL PROTECTED]> writes: > As I try this with SQLITE 3.0.4, I get "database is locked" error at > step 4. > > Are you not getting the lock out error? Yes, because there is a transaction in progress in Process 2, the database may not be written to by Process 1, so without a busy-wai

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Wei Chin
Darrell and everyone, As I try this with SQLITE 3.0.4, I get "database is locked" error at step 4. Are you not getting the lock out error? Wei [EMAIL PROTECTED] wrote on 9/1/2004, 10:04 AM: > TimeProcess 1 Process 2 >

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Ara.T.Howard
On Wed, 1 Sep 2004, Christian Smith wrote: A transaction gives you a snapshot in time of the database. You may need to do more than one query, and require a consistent snapshot for the duration of the multiple queries. this is definitely a real world need - in my latest code i have a 'snapshot' met

RE: [sqlite] Locking in 3.0.5

2004-09-01 Thread Keith Herold
To: [EMAIL PROTECTED] Subject: Re: [sqlite] Locking in 3.0.5 On Wed, 1 Sep 2004, Matt Wilson wrote: >On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote: >> >> Add a new "BEGIN [TRANSACTION] FOR READONLY" statement, which begins >> the tran

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Derrell . Lipman
Matt Wilson <[EMAIL PROTECTED]> writes: > On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote: >> >> 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 loc

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Christian Smith
On Wed, 1 Sep 2004, Matt Wilson wrote: >On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote: >> >> 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.

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Matt Wilson
On Wed, Sep 01, 2004 at 02:46:39PM +0100, Christian Smith wrote: > > 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. Why do you need a transaction at all if you

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Christian Smith
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, Septe

Re: [sqlite] Locking in 3.0.5

2004-09-01 Thread Miguel Angel Latorre
us 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

RE: [sqlite] Locking in 3.0.5

2004-08-31 Thread Rob Groves
>>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 pro

Re: [sqlite] Locking in 3.0.5

2004-08-31 Thread D. Richard Hipp
Rob Groves wrote: I have just read the archive mailing list from 16/08/2004, and it looks like this behaviour is on purpose (checkin 1879). So, Rob, are you go to tell us if you think the change is an improvement or not? -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565

RE: [sqlite] Locking in 3.0.5

2004-08-31 Thread Rob Groves
I have just read the archive mailing list from 16/08/2004, and it looks like this behaviour is on purpose (checkin 1879). My mistake, Rob. -Original Message- From: Rob Groves [mailto:[EMAIL PROTECTED] Sent: 31 August 2004 22:17 To: [EMAIL PROTECTED] Subject: [sqlite] Locking in 3.0.5

[sqlite] Locking in 3.0.5

2004-08-31 Thread Rob Groves
Hi, I have observed different behaviour between 3.0.3 and 3.0.5. I didn't download 3.0.4 so can't comment on that. I am using two threads and setting a busy timeout on each with sqlite3_busy_timeout(). In 3.0.3 two threads trying to update the same row(s) would both retry until the one with the