The preceding test was with SQLiteDatabase.setLockingEnabled(true), the default.
With SQLiteDatabase.setLockingEnabled(false), the reading thread is not starved. Behavior seemed similar to when a transaction was not used. And my tests run successfully. I may be getting lucky and/or my tests are not good enough to break it yet. Nathan On Jan 26, 3:47 pm, jotobjects <[email protected]> wrote: > 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
