Speaking of documentation of locks... my one beef with the sqlite documentation is that its not very explicit about implicit locking. To find out about implicit locks, you have to read http://www.sqlite.org/lang_transaction.html, even though implicit locks aren't necessarily associated with transactions. The C API functions that actually manage these locks just mention them in passing.
To me, it makes sense to have a blurb like: "For 'step' to succeed, the database must either be unlocked, or have no more than a SHARED lock upon it. Upon successful completion of this function, the database lock state will be SHARED. (For this lock to be undone, all statements in the executed state must be either reset or finalized.)" at http://www.sqlite.org/c3ref/step.html, since its an important side-effect of the function. And perhaps have similar text in all other functions that manipulate the implicit lock. -John On Mon, Dec 15, 2008 at 12:15 PM, Mike Mestnik <mmest...@visi.com> wrote: > On Mon, Dec 15, 2008 at 11:40:45AM -0600, Jay A. Kreibich wrote: >> On Mon, Dec 15, 2008 at 09:08:34AM -0600, Mike Mestnik scratched on the wall: >> > The locking is well documented, but it's not vary clear that the >> > BEGIN command can be used to acquire locks. The relation between the >> > different locking stats and parameters to the BEGIN command could be >> > spelled out. >> >> You might have missed this. Assuming you understand the locking >> system, it does a pretty good job at filling in the details on BEGIN. >> >> http://www.sqlite.org/lang_transaction.html >> >> Transactions can be deferred, immediate, or exclusive. The default >> transaction behavior is deferred. Deferred means that no locks are >> acquired on the database until the database is first accessed. Thus >> with a deferred transaction, the BEGIN statement itself does nothing. >> Locks are not acquired until the first read or write operation. The >> first read operation against a database creates a SHARED lock and the >> first write operation creates a RESERVED lock. Because the acquisition >> of locks is deferred until they are needed, it is possible that another >> thread or process could create a separate transaction and write to the >> database after the BEGIN on the current thread has executed. If the > > At this time I have more then enough information to complete my > project, thank you so much for all the help. > >> transaction is immediate, then RESERVED locks are acquired on all >> databases as soon as the BEGIN command is executed, without waiting for > > I think text like the above is missing for each of the BEGIN > arguments. To make things easy to find it might also be good to put > some BEGIN examples into the page that explains how locking works. > > DEFERRED/default, then initially ??no?? locks. > IMMEDIATE, then initially RESERVED lock. > EXCLUSIVE, then initially ? lock. > > There are more locks then there are BEGIN arguments, correct? Perhaps > an explanation on why BEGIN has no support for creating this type of > lock. > > I also wonder about nested begins? For example when you want to > explicitly change an EXCLUSIVE lock into a IMMEDIATE one, or the > other way around. > > > Perhaps my confusion simply comes from a lack of understanding basic > SQL concepts. > >> the database to be used. After a BEGIN IMMEDIATE, you are guaranteed >> that no other thread or process will be able to write to the database >> or do a BEGIN IMMEDIATE or BEGIN EXCLUSIVE. Other processes can >> continue to read from the database, however. An exclusive transaction >> causes EXCLUSIVE locks to be acquired on all databases. After a BEGIN >> EXCLUSIVE, you are guaranteed that no other thread or process will be >> able to read or write the database until the transaction is complete. >> >> >> >> -- >> Jay A. Kreibich < J A Y @ K R E I B I.C H > >> >> "Our opponent is an alien starship packed with atomic bombs. We have >> a protractor." "I'll go home and see if I can scrounge up a ruler >> and a piece of string." --from Anathem by Neal Stephenson > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
