Although I am not sure about the object itself, AFAIK a single SQL statement is atomic, so your database itself will hopefully never lock. If the object accessing it is not thread safe, I could see that locking, but as Mark mentioned, I think getting a new SQLiteDatabase is relatively 'cheap'.
I know that's not exactly what you were looking for, but it's my two cents Hamy On May 24, 9:07 am, Matt Williams <[email protected]> wrote: > > I'd reverse the question: if you aren't exposing the data to other > > applications, what are you *gaining* by using ContentProvider? If you > > want a model class to hide your database internals, you can roll one of > > those without ContentProvider. > > There are 2 reasons why I had decided on a content provider > > Confusion over the Application model. > Traditionally, I would have initialized my database as part of the > main applications startup process, but from the code examples I've > seen people seemed to be doing it all on a per activity basis, which > just seemed like repeating myself. > > Lack of knowledge of thread-safe access to the database. > I'm using a few threads that may attempt concurrent writes on the > database. There doesn't seem to be any documentation on whether > SQLDatabase its thread-safe or not, whereas I just assumed a > ContentProvider would be. If I was to instantiate the database in the > Application as a static singleton, am I correct in assuming that I > would only need to set the method that queries the database to > synchronized? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
