On Sep 28, 2:09 pm, Mark Murphy <mmur...@commonsware.com> wrote: > GeezIHateCreatingNewNames wrote: > > The more complicated case > > seems to be a single application that has two processes in it (e.g, an > > application with a long running service). > > You do not need two processes for an application with a long running > service. Not to mention that long-running services aren't a great idea > in the first place.
While it's not a common case, there ARE cases in which it makes sense to have a long running service with two processes. The case I have in mind involves a media player with all the associated content management. I agree that in most cases it's a bad idea to have long- running services or two processes, because most services are of the "wake up when there is something to do" model. > > In this case it seems like > > you could simply share at the sqlite database layers, but the locking > > and sharing story on the sqlite database APIs is somewhat unclear. > > SQLite handles cross-process locking. There are two layers involved. I have a lot of confidence in the underlying native layer, which has a pretty clear story on the various levels of locking (database, table, or page-level). Write locks are accomplished by locking the entire database, which is perhaps ok if most of your access is to read. More sophisticated databases will allow simultaneous writes from different processes by page-level or table-level locking, but at least SQLite has a clear guarantee and a reasonable expectation of performance. See http://www.sqlite.org/lockingv3.html for a more thorough discussion. On the other hand, the android SQLite API on top of the native layer is a different animal. In particular if you look in SQLiteOpenHelper.getReadableDatabase() there is a line that says "return getWritableDatabase()". That's one way of satisfying lock constraints, but it also seems to imply that all locks (read or write) are exclusive to a process and lock the entire database. If an application in one process has a CursorAdapter, then it will periodically have to reacquire a lock in order to call SQLiteQuery.fillWindow(), but if there is another process writing to the database, then the application is going to block. I haven't unwound the spaghetti to resolve this issue, and the documentation is unclear on the point. I am not claiming that "there is a consistency problem"; only that there is a lot of ambiguity about what kind of performance will be delivered, and what the semantics are on locking at the android API layer. That's why I was advocating the use of the ContentProvider APIs, because it says that it uses a single process to handle locking. Thus there is no doubt that you can have multiple readers because the lock will be shared. Kevin McCurley > That's one of the reasons why it is the default database for Rails and other > Ruby server-side frameworks > that rely on multiple processes. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android Development Wiki:http://wiki.andmob.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
