Interesting. Thanks for that link. It is a reasonable "speculation" (guess) that the enable locking method has "something" to do with the various threading options. In addition to thread safe operation there is the question of how multiple processes (different JVMs) inter-operate with the same SQLLite database. Database engines usually isolate parallel transactions for multiple clients. Which brings us back to the question of what are the semantics of the Adnroid API "beginTransaction" method? And maybe the intended best practice programming model is to wrap these operations inside a ContentProvider.
On Jan 21, 5:42 pm, Nathan <[email protected]> wrote: > On Jan 21, 4:22 pm, jotobjects <[email protected]> wrote: > > > > > It doesn't make any sense to me that you have to turn locking on > > (whatever that means) if you are using transactions. > > You probably don't if you are using one thread. > > I think the setLocking is about making the the SQLite *code* thread > safe, and not about enabling or disabling transactions. > > It's probably this:http://www.sqlite.org/threadsafe.html > > Assuming the binary on Android has been compiled as threadsafe, it is > probably whether or not the connection is opened as threadsafe. You > don't get direct access to connections through the interface (not that > I miss them). No word on whether this mean "MultiThread" mode or > "Serialized" mode, but I would guess serialized as it is the default. > Somewhere deep in there, a call is being made to sqlite3_open_v2() > with that parameter. > > 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
