| 03bd302aebbb77f4f95789a269c8a5463ac5a840 |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Don't close the database until all references released.
SQLiteDatabase.close() should call releaseReference() rather than
closing the database immediately. SQLiteDatabase should also hold
a reference to itself while performing certain operations to
ensure that they complete normally even if another thread closes
the database at the same time.
Fixed a couple of missing or redundant uses of acquireReference()
related to CursorWindows.
To be honest, the reference counting performed by SQLiteClosable should
not be needed, but we're stuck with it in the API.
Bug: 6104842
Change-Id: I3444a697409905d4a36b56418dc7766f5ba76b59
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| e5360fbf3efe85427f7e7f59afe7bbeddb4949ac |
|
01-Nov-2011 |
Jeff Brown <jeffbrown@google.com> |
Rewrite SQLite database wrappers.
The main theme of this change is encapsulation. This change
preserves all existing functionality but the implementation
is now much cleaner.
Instead of a "database lock", access to the database is treated
as a resource acquisition problem. If a thread's owns a database
connection, then it can access the database; otherwise, it must
acquire a database connection first, and potentially wait for other
threads to give up theirs. The SQLiteConnectionPool encapsulates
the details of how connections are created, configured, acquired,
released and disposed.
One new feature is that SQLiteConnectionPool can make scheduling
decisions about which thread should next acquire a database
connection when there is contention among threads. The factors
considered include wait queue ordering (fairness among peers),
whether the connection is needed for an interactive operation
(unfairness on behalf of the UI), and whether the primary connection
is needed or if any old connection will do. Thus one goal of the
new SQLiteConnectionPool is to improve the utilization of
database connections.
To emulate some quirks of the old "database lock," we introduce
the concept of the primary database connection. The primary
database connection is the one that is typically used to perform
write operations to the database. When a thread holds the primary
database connection, it effectively prevents other threads from
modifying the database (although they can still read). What's
more, those threads will block when they try to acquire the primary
connection, which provides the same kind of mutual exclusion
features that the old "database lock" had. (In truth, we
probably don't need to be requiring use of the primary database
connection in as many places as we do now, but we can seek to refine
that behavior in future patches.)
Another significant change is that native sqlite3_stmt objects
(prepared statements) are fully encapsulated by the SQLiteConnection
object that owns them. This ensures that the connection can
finalize (destroy) all extant statements that belong to a database
connection when the connection is closed. (In the original code,
this was very complicated because the sqlite3_stmt objects were
managed by SQLiteCompiledSql objects which had different lifetime
from the original SQLiteDatabase that created them. Worse, the
SQLiteCompiledSql finalizer method couldn't actually destroy the
sqlite3_stmt objects because it ran on the finalizer thread and
therefore could not guarantee that it could acquire the database
lock in order to do the work. This resulted in some rather
tortured logic involving a list of pending finalizable statements
and a high change of deadlocks or leaks.)
Because sqlite3_stmt objects never escape the confines of the
SQLiteConnection that owns them, we can also greatly simplify
the design of the SQLiteProgram, SQLiteQuery and SQLiteStatement
objects. They no longer have to wrangle a native sqlite3_stmt
object pointer and manage its lifecycle. So now all they do
is hold bind arguments and provide a fancy API.
All of the JNI glue related to managing database connections
and performing transactions is now bound to SQLiteConnection
(rather than being scattered everywhere). This makes sense because
SQLiteConnection owns the native sqlite3 object, so it is the
only class in the system that can interact with the native
SQLite database directly. Encapsulation for the win.
One particularly tricky part of this change is managing the
ownership of SQLiteConnection objects. At any given time,
a SQLiteConnection is either owned by a SQLiteConnectionPool
or by a SQLiteSession. SQLiteConnections should never be leaked,
but we handle that case too (and yell about it with CloseGuard).
A SQLiteSession object is responsible for acquiring and releasing
a SQLiteConnection object on behalf of a single thread as needed.
For example, the session acquires a connection when a transaction
begins and releases it when finished. If the session cannot
acquire a connection immediately, then the requested operation
blocks until a connection becomes available.
SQLiteSessions are thread-local. A SQLiteDatabase assigns a
distinct session to each thread that performs database operations.
This is very very important. First, it prevents two threads
from trying to use the same SQLiteConnection at the same time
(because two threads can't share the same session).
Second, it prevents a single thread from trying to acquire two
SQLiteConnections simultaneously from the same database (because
a single thread can't have two sessions for the same database which,
in addition to being greedy, could result in a deadlock).
There is strict layering between the various database objects,
objects at lower layers are not aware of objects at higher layers.
Moreover, objects at higher layers generally own objects at lower
layers and are responsible for ensuring they are properly disposed
when no longer needed (good for the environment).
API layer: SQLiteDatabase, SQLiteProgram, SQLiteQuery, SQLiteStatement.
Session layer: SQLiteSession.
Connection layer: SQLiteConnectionPool, SQLiteConnection.
Native layer: JNI glue.
By avoiding cyclic dependencies between layers, we make the
architecture much more intelligible, maintainable and robust.
Finally, this change adds a great deal of new debugging information.
It is now possible to view a list of the most recent database
operations including how long they took to run using
"adb shell dumpsys dbinfo". (Because most of the interesting
work happens in SQLiteConnection, it is easy to add debugging
instrumentation to track all database operations in one place.)
Change-Id: Iffb4ce72d8bcf20b4e087d911da6aa84d2f15297
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 36c4cec85346a11e136b0f95baae2a8fe1db59f2 |
|
04-Jan-2011 |
Vasu Nori <vnori@google.com> |
don't call methods doing database lock from a synchronized block
bug:3188552
Change-Id: I08a73f06aa0cbefddd282885f62b8dcc451b9deb
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 02fc2b01a3fa1cdd0240087726259cca1b4df910 |
|
28-Oct-2010 |
Vasu Nori <vnori@google.com> |
cleanup some of the STOPSHIP comments
removing a check no longer required.
bug:3143859
Change-Id: I6a2ed242d234a4eb78b116bde81efd31e82fafaf
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 4d76d0b8329707a0b71c6e6ff04ed47e93d5582c |
|
21-Sep-2010 |
Vasu Nori <vnori@google.com> |
STOPSHIP follow up to Change-Id: I392875b62ed270741633f5bffa519932e4a9f985
adding back an object that originally existed (when the bug appeared randomly)
Change-Id: Ie6fef529e7b366aaecaace5d3409f2cdc551c8ae
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 23221192a0a0c7b7c2841c8404063a7c290ea106 |
|
16-Sep-2010 |
Vasu Nori <vnori@google.com> |
change error message on cl I392875b62ed270741633f5bffa519932e4a9f985
Change-Id: I9eaf201822a9efd8afbdf5cd0e7ef2f01749b955
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 6728ebfa9282a12ec437e8b878ab9e60be97b22a |
|
16-Sep-2010 |
Vasu Nori <vnori@google.com> |
STOPSHIP some debugging code to help find reproducible testcases
sometimes mReferenceCount in SQLiteCloasable.java has some huge number
(a memory address probably)
this causes a database.close() or sqliteStatement.close() to randomly
fail and not release the object. and that usually causes a finalizer
warning or sqlite to return error "dbclose failed due to
unfinalised statements"
Change-Id: I392875b62ed270741633f5bffa519932e4a9f985
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 196663234ab1b67fdd88060701e8211f67fd7854 |
|
10-Sep-2010 |
Vasu Nori <vnori@google.com> |
remove unnecessary synchronization object from SQLiteClosable.
and a couple of other minor SMP fixes
Change-Id: I62bb4dd2fe43fc41074454a25bd84ad1fb4d004d
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 441fcf13f3bbfd2fb9de273d3d552aad2a7ae9af |
|
08-Sep-2010 |
Vasu Nori <vnori@google.com> |
remove some useless code and add some code to aid in debugging
Change-Id: Ie532848b82dde57cc7a7017661679ece06ca606e
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| c3849200fa60b22ea583ba2a6f902d6a632a5e7e |
|
09-Mar-2010 |
Vasu Nori <vnori@google.com> |
add more debug info to SQL section in bugreport
after this CL, adb bugreport will the following info (under SQL section
of each app's meminfo dump)
SQL
heap: 344 memoryUsed: 344
pageCacheOverflo: 67 largestMemAlloc: 50
DATABASES
Pagesize Dbsize Lookaside Dbname
1024 7 24 googlesettings.db
1024 26 110 talk.db
1024 11 0 (attached) transient_talk_db
1024 11 32 subscribedfeeds.db
1024 20 27 gservices.db
Change-Id: Iabd13be9793d9794137c60a045b84fa632f13498
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 9ffdfa0c238fce3b85741d7f6828fd484cd8f195 |
|
09-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Speed up ContentProvider.query() in simple case by ~30%
When query() uses bulkQuery() and we know we're going to need some
metadata right afterwards (number of rows and column index of _id, if
present), just asked for it in the initial binder transaction instead
of immediately fetching it again.
Also, this defers loading column names until the client asks for them.
This gets down the simpler (and very common) use cases of
ContentProvider.query() down to 3 binder calls:
QUERY_TRANSACTION to android.content.ContentProvider$Transport
GET_CURSOR_WINDOW_TRANSACTION to android.database.CursorToBulkCursorAdaptor
CLOSE_TRANSACTION to android.database.CursorToBulkCursorAdaptor
More can still be done, but this is a good bite-sized first piece.
Change-Id: I7ad45949f53e0097ff18c2478d659f0f36929693
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| d3fe30134edbe17094a5b9ef21aa6662de451001 |
|
19-Feb-2010 |
Vasu Nori <vnori@google.com> |
add diagnostic info to help debug bug:2427686
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 3ef94e25b4c896ecaa85aa2c12b8863ecdf98df0 |
|
05-Feb-2010 |
Vasu Nori <vnori@google.com> |
use sqlite 3.6.22 to print and profile the sql statetements
instead of rolling our own trace/profile code in java, lets use
sqlite 3.6.22 features. turns out sqlite does a good job of
printing the sql statements - including the ones from the triggers.
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/database/sqlite/SQLiteClosable.java
|