Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-16 Thread Daniel K
--- Christian Smith <[EMAIL PROTECTED]> wrote: > On Wed, 16 Jun 2004, Daniel K wrote: > > >--- [EMAIL PROTECTED] wrote: > >> > >> > http://www.sqlite.org/lockingv3.html > >> > >> My thoughts are listed as they come to me. > >> > >> Thought 1: > >> > >> Section 5.0, entitled "Writing to a databas

Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-16 Thread Christian Smith
On Wed, 16 Jun 2004, Daniel K wrote: >--- [EMAIL PROTECTED] wrote: >> >> > http://www.sqlite.org/lockingv3.html >> >> My thoughts are listed as they come to me. >> >> Thought 1: >> >> Section 5.0, entitled "Writing to a database file": >> After the in-memory cache initially spills to disk >> the

Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-16 Thread Daniel K
--- [EMAIL PROTECTED] wrote: > G'day, > > > > > > "D. Richard Hipp" <[EMAIL PROTECTED]> > 12/06/2004 08:16 AM > > > To: [EMAIL PROTECTED] > cc: > Subject: [sqlite] Locking and > conc

Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-16 Thread ben . carlyle
G'day, "D. Richard Hipp" <[EMAIL PROTECTED]> 12/06/2004 08:16 AM To: [EMAIL PROTECTED] cc: Subject: [sqlite] Locking and concurrency in SQLite version 3.0 > http://www.sqlite.org/lockingv3.html My thoughts are listed as the

Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-12 Thread D. Richard Hipp
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

Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-12 Thread D. Richard Hipp
Christian Smith wrote: "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

Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-12 Thread Christian Smith
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

Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-12 Thread Darren Duncan
At 6:16 PM -0400 6/11/04, 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 Rea

Re: [sqlite] Locking and concurrency in SQLite version 3.0

2004-06-11 Thread Tito Ciuro
Hello Dr. Hipp, I have a question about the following section: If the SQL COMMIT command turns autocommit on and the autocommit logic then tries to commit change but fails because some other process is holding a SHARED lock, then autocommit is turned back off automatically. This allows the user

[sqlite] Locking and concurrency in SQLite version 3.0

2004-06-11 Thread D. Richard Hipp
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 Readers who are so inclined are encouraged to read t