Transactions. Handling this sort of concurrency is largely what databases are all about. Read any introduction to databases. Pay special attention to the so-called "ACID" properties -- Atomicity, Consistency, Isolation, and Durability.
The basic idea is that you choose your transaction boundaries to control what states the other accessors of the database can see. One other factor to keep in mind: Android service lifecycle methods and activity lifecycle methods run in the same thread. This means they will not be running at the same time. Only if you have an async task, or start up a thread, will you have true concurrency. It's still good practice to design your transactions so that concurrent access will see the right thing. For one thing, it means that error handling will not leave you in an inconsistent state. In particular, if you begin a transaction, make a number of updates to your data, and then get an exception and exit without marking the transaction successful, then your incomplete changes will be discarded. This property by itself is reason enough to use a database, even without considering concurrent access. On Jun 14, 2:50 am, gadjou <[email protected]> wrote: > Hello, > I have an activity which starts a (intent)service. Both access the > same DB and potentially write to the same table. > What design pattern would you recommand to avoid concurrency? > > Thanks > Jérôme -- 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
