Thanks for that report. Did your transaction test also have the enable locking set? That may have had a worst case exclusive locking effect (SQLite does not use exclusive write locks until commit time normally).
FAQs 5 and 6 at this link provide more info - http://www.sqlite.org/faq.html#q5 How the Android API transaction maps to the concept of a SQL transaction and what the enable locking method means are entirely Android domain questions - so SQLite documentation only tell half the story. For instance this link says that reads are allowed during a transaction - http://www.sqlite.org/lang_transaction.html On Jan 26, 2:52 pm, Nathan <[email protected]> wrote: > >Database engines > > usually isolate parallel transactions for multiple clients. > > Don't count on SQLite doing this. Any locks are on the entire database > file - only one transaction can be in progress. > > I do have some data based on some tests I've run. > > Having a cursor open does not lock the database, and writes can > proceed. That's good. > > I've run two parallel threads, with the main thread reading blobs from > the database using SQLiteDatabase.query(), and a secondary thread > writing blobs to the database withht SQLiteDatabase.insert(), both in > long running loops. > > Results: > They could both complete normally. The database is probably locked for > only a short time when a blob is being written, so they probably trade > off pretty well. > > If, however, I place the entire write loop in a transaction, the > database is locked as of beginTransaction(), and the main thread will > block on an SQLiteDatabase.query until *all* of the write loop has > completed. > > Therefore, transactions can be horrible for performance if they are > too small (ie 1000s of tiny transactions). But if they are too long, > they can starve other threads for their duration. If the other thread > happens to be the UI thread, you can expect to be force-closed in 4 > seconds. > > So expect a love/hate relationship with transactions, based on these > performance issues, without even bringing up database consistency, > which is the primary purpose of transactions. > > Nathan -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
