On Jan 21, 11:08 am, jotobjects <jotobje...@gmail.com> wrote: > You might want to look into the transaction paradigm/pattern: > > http://developer.android.com/reference/android/database/sqlite/SQLite... > > Transactions are the well understood way to get consistent results > with multiple readers and writers. Exactly what the semantics are for > transaction in the Android database.sqllite API is not clear to me.
My experience with SQLite in .NET Compact Framework has given me enough motivation to ask these kind of questions. Using transactions - or not using them - can have unexpected SQLite performance implications even in a single threaded world. Once a simple xml import was taking up to half an hour. I put a transaction around a long series of small updates and it was reduced to a few seconds. This was a situation where you would think a transaction would improve correctness, but degrade performance slightly. The questions I have are: Does a Cursor hold a lock while it it being used, for example, in a SimpleCursorAdapter? Does a transaction hold a lock starting at Begingtransaction ? Long transactions can be bad if I wish to keep the write lock short. This is a discussion of locking in SQLite3: http://www.sqlite.org/lockingv3.html I don't know how the SQLiteDatabase interface interacts with this model yet. > For instance, when you would want to or need to use the > setLockingEnabled method and how that relates to using transactions is > unclear. > I think that I don't have any choice about setLockingEnabled - SQLite will probably crash without it. I don't expect that it will solve all problems, though. 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
