On Jan 21, 12:09 pm, Nathan <[email protected]> wrote:
> 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. That is not so surprising since without a transaction every update is essentially its own tranaction that requires a commit to the database. Wrapping many of these in a transaction does all the updates in one commit. > > This is a discussion of locking in SQLite3: > > http://www.sqlite.org/lockingv3.html > That's pretty low level until you get to section 7 at the end of that description where it says what actually happens with SQL transactions. Which still doesn't help much since the Android API is not SQL. > I don't know how the SQLiteDatabase interface interacts with this > model yet. Yes that is the question since the Android class uses SQL-like terms (e.g., BeginTransaction) but isn't actually using SQL semantics. We have to read the source code and understand the underlying SQLLite api that Android implements on top of to understand what is happening. > > > 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. It doesn't make any sense to me that you have to turn locking on (whatever that means) if you are using transactions. What "turning locking on" means if you are not using transactions is also a total mystery -- 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
