History log of /packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
ae32283e7fc5b749df96523d8bb343b9068b65ba 09-May-2012 Makoto Onuki <omakoto@google.com> Fix transaction handling in the provider

Fixed issues that will happen when a batch operation for applyBatch()
contain operations for both the contacts db and the profile db.

- Make sure to set the right transaction listener when starting a transaction.
There were cases where we started a transaction on the contacts db but passsing
the profile provider as the listener, and vice versa.

- Make sure transaction callbacks operate on the correct DB.
There were cases where ContactsProvider2.onCommit() and its sbilings would
operate on the profile DB, not on the contacts db.

- Change the transaction finishing order.
When we start transactions on both the contacts and the profile DB, we do so
on the contacts db first, and then on the profile db. But when we clsoe them,
we did it in the same order, which could potentially cause a deadlock.
Now we close them in the reverse order; the profile db first, then the
contacts db.

- Remove mActiveDb.
This wasn't set in switchTo{Profile,Contact}Mode(), but was lazily initialized.
But I wasn't too sure if I always set the right db at the right timing.
Looks like I forgot to do so in a few cases. Let's just remove it and always
explicitly get the database from the current db helper.

Bug 6250673

Change-Id: Idd18fc173596c973d0ff8b6e1b2456715c0f14f8
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
74e8f30b3a67af4defd8f73c503e794785671fee 03-Feb-2012 Makoto Onuki <omakoto@google.com> Add debug logs to applyBatch

Change-Id: I646c7e091c2e778516e6287e3e91770e556ad71f
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
b91899a113c499ef96fe5719398558b4cfd128c2 01-Nov-2011 Dave Santoro <dsantoro@google.com> Fix double-close of transactions if yields fail.

This was causing the exception that caused the failed yield to be
swallowed instead of propagated, as the second close was failing
due to lack of a DB lock on the thread.

Bug 5515111

Change-Id: Ic847801655b28301913b07b3929794b3ba16c5ae
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
376917cea44aec4dfd68dec23522353b142535fd 06-Oct-2011 Dave Santoro <dsantoro@google.com> Allow multiple inserts in bulk between yields.

This should help to optimize these operations to avoid the overhead
of doing lots of individual inserts when the database is very active.

Bug 5353552

Change-Id: I5b3a06f41637452ec98297c66579fb7d4f81e2ec
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
6efb7db26598b105342d02207e0ca1c8725c10da 22-Sep-2011 Dave Santoro <dsantoro@google.com> Fixes and cleanup for transactions.

- Make the thread-local transaction shared between the contacts and
profile providers (as the implementation intended).
- Remove a bunch of extraneous variables from the contacts provider.
- Ensure that the profile provider switches the delegate into profile
mode before running onBegin() or onCommit().
- Port the fix for applying contact changes to the profile DB.
- Fix an issue with profile aggregation after the profile has been
deleted.
- Addressed a case in which we would create (and possibly hold onto)
a profile DB transaction erroneously.
- Ported fix for aggregation when raw contacts are deleted.

Bug 5320369

Change-Id: I1f36d4c87c6b655dfcb5e339f151d3bf1d37a437
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java
078f588cef389358adabc579de00747878f3c108 21-Sep-2011 Dave Santoro <dsantoro@google.com> Refactor transactions for contacts.

Rather than extending SQLiteContentProvider, the profile and contacts
providers now extend AbstractContactsProvider, which handles keeping
track of a thread-local transaction with awareness of what databases
have been enlisted in the transaction and whether it is being run in
the context of a batch operation.

This is intended to solve the issue of how the content provider can
manage transactions that operate across multiple databases without
risking deadlocks.

Bug 5320369

Change-Id: I08a7d518a3eae1b0bf438402d02f1f1d8e8df7b9
/packages/providers/ContactsProvider/src/com/android/providers/contacts/AbstractContactsProvider.java