I would really like to try the changes, but I'm not set up to build from CVS. Can you make a source code zip file available with the preprocessing and code generation done already?
--Ned. http://nedbatchelder.com -----Original Message----- From: D. Richard Hipp [mailto:[EMAIL PROTECTED] Sent: Monday, October 04, 2004 11:03 PM To: [EMAIL PROTECTED] Subject: [sqlite] Locking enhancments The code in CVS contains enhancements to transactions to help people work around the so-called "deadlock" issues they have been having. Those who are able are encouraged to try out the latest code in CVS. If no problems are reported within the next week, I will release version 3.0.8 that contains the new features. Note that technically, SQLite has never been able to deadlock. It is possible that two or more processes or threads could be contending for the same lock. But eventually, all but one of the processes would time out and allow one process to continue. SQLite has never used blocking locks so a true deadlock was never possible. Though the locking contention could result it signficant delays if not handled properly. SQLite has always allowed you to do transactions as follows: BEGIN TRANSACTION; -- queries and updates here COMMIT TRANSACTION; (Aside: the TRANSACTION keyword is optional and is usually omitted. I've included it here for completeness.) Beginning with code checked in earlier today, it is now possible to specify three different types of transactions: BEGIN DEFERRED TRANSACTION; BEGIN IMMEDIATE TRANSACTION; BEGIN EXCLUSIVE TRANSACTION; (Again: the TRANSACTION keyword is optional.) The default behavior is a deferred transaction. A deferred transaction works like version 3.0 has always worked. With a deferred transaction, no locks are acquired on any database until there is I/O against that database. The first time a database is read, a SHARED lock is acquired. The first time a database is written, a RESERVED lock is acquired. Deferred transactions give more concurrency, but they were also create the greatest opportunity for lock contention. An immediate transaction creates a RESERVED lock on all attached databases as soon as the BEGIN statement executes. Other processes and/or threads can continue to read the databases but no other process will be able to write to a database until the transaction ends. Immediate transactions provide less concurrency but are also less likely to cause lock contention. An exclusive transaction creates an EXCLUSIVE lock on all attached databases as soon as the BEGIN command executes. This is how version 2.8 works. This method gives you the least amount of concurrency but eliminates the problem of lock contention. Again, the default behavior continues to be DEFERRED and there is (currently) no way to change the default behavior. So if you want to use one of the new locking modes, you have to specify the mode you want in the BEGIN statement. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
