>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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
