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
