| a7771df3696954f0e279407e8894a916a7cb26cc |
|
08-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Move CancellationSignal to android.os package.
Bug: 6427830
Change-Id: I39451bb1e1d4a8d976ed1c671234f0c8c61658dd
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 4c1241df8f8b7fd5ec3dff6c7e0f66271248e76e |
|
03-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Rename CancellationSignal using preferred spelling.
Bug: 5943637
Change-Id: I12a339f285f4db58e79acb5fd8ec2fc1acda5265
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 75ea64fc54f328d37b115cfb1ded1e45c30380ed |
|
26-Jan-2012 |
Jeff Brown <jeffbrown@google.com> |
Implement a cancelation mechanism for queries.
Added new API to enable cancelation of SQLite and content provider
queries by means of a CancelationSignal object. The application
creates a CancelationSignal object and passes it as an argument
to the query. The cancelation signal can then be used to cancel
the query while it is executing.
If the cancelation signal is raised before the query is executed,
then it is immediately terminated.
Change-Id: If2c76e9a7e56ea5e98768b6d4f225f0a1ca61c61
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.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/SQLiteQuery.java
|
| d5064be3b5922ee6522a33f8b729ffee2e3d7b4b |
|
14-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Make SQLiteQuery and SQLiteProgram final.
We can do this because the classes already cannot be subclassed
by applications due to the fact they only have package private
constructors.
One very nice consequence of this observation is that we can hide or
delete several @deprecated protected members which are effectively
inaccessible because applications cannot create subclasses!
Change-Id: I2d3a0d2ad72b9289ebcdf907e4e4e6caf27f9076
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| fa59cfbc85af0a8774f0f3e496c06ad8c62c1951 |
|
31-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of bce45617 to master
Change-Id: Ieb966e674dca3ec46cd3cd25e4de281f1be747c2
|
| 89101cd9d9b5c1a6ff1ed85eba0613ca4c4802e2 |
|
28-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Improve the slow query instrumentation.
On user-debug and eng builds, you can set the
"db.log.slow_query_threshold" system property to queries that
take longer than the specified number of milliseconds.
Set it to 0 to log all queries.
This property has been around for a while but it was implemented
poorly. In particular, it *changed* the behavior of the query
by calling getCount() while holding the Db connection.
In normal operation, the query will not actually run until later.
By putting the timing logic into fillWindow() instead, we ensure
that we only measure queries that actually ran. We also capture
cases where the cursor window gets filled multiple times.
Bug: 5520301
Change-Id: I174f5e1ea15831a1d22a36e9a804d7755f230b38
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 650de3dcfcbc7635da3c070410ef1dc4027ae464 |
|
27-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Optimize fillWindow to improve reverse-seek performance.
Bug: 5520301
When an application requests a row from a SQLiteCursor that
is not in the window, instead of filling from the requested
row position onwards, fill from a little bit ahead of the
requested row position.
This fixes a problem with applications that seek backwards
in large cursor windows. Previously the application could
end up refilling the window every time it moved back
one position.
We try to fill about 1/3 before the requested position and
2/3 after which substantially improves scrolling responsiveness
when the list is bound to a data set that does not fit
entirely within one cursor window.
Change-Id: I168ff1d3aed1a41ac96267be34a026c108590e52
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 7ce745248d4de0e6543a559c93423df899832100 |
|
07-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Clean up CursorWindow lifetime.
Bug: 5332296
Removed dead code in SQLiteCursor related to the use of a background
query thread. This code could result in CursorWindows being modified
concurrently or used after free. This code is broken, unused and
is just in the way.
Added comments to explain how CursorWindow ownership is
supposed to work for AbstractWindowedCursors. (There are still cases
where cursor windows get dropped on the floor without being closed.
Those will be taken care of in a subsequent patch.)
Cleaned up SQLiteQuery.fillWindow to eliminate duplicate code and
remove bits that were only needed for background loading, like
returning -1.
Change-Id: I03e8e2e73ff0c11df76d63f57df4c5ada06ae1cb
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 3bc6bbc92cd2095f42039b5aadd0a14d0e5d9230 |
|
06-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Clean up CursorWindow code.
Bug: 5332296
The code is functionally equivalent, but a little more efficient
and much easier to maintain.
Change-Id: I90670a13799df05831843a5137ab234929281b7c
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 16057fad00d47e920fc20721b70c7cafb765f7f8 |
|
18-Mar-2011 |
Vasu Nori <vnori@google.com> |
fix broken logTimeStat stuff
log time in the following 2 situations
1. all transactions. time measured = wall time between begin-commit
2. queries (which are not in tranactions)
Change-Id: I67be9487a96072695aff3529ba4a257f4c8ec596
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| b18f27dbf43ee9028a11cafbca23d3fa318e278b |
|
13-Aug-2010 |
Vasu Nori <vnori@google.com> |
Return count of rows in a resultset only once (when startPos = 0)
If a query returns 100 rows and say only 10 rows fit in 1MB, then client
receiving the cursor from the ContentProvider needs to paginate.
ContentProvider returns count of total data everytime it returns a page
(= 1MB) of data to the client.
Returning total count causes reading (and skipping unwanted) data
from sqlite.
Instead, it should be sufficient to get total count once
and re-use the count value during the life of the cursor
until a requery is performed on the cursor.
(Count won't change unless data is changed - in which case
the cursor is asked to perform requery anyway. So doing count
once and reusing it should work)
Change-Id: I3520d94524dda07be9bcff56b6fbae5276af1d3b
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 0732f7912ccec9a1cc379b535ac0b56ae50972b3 |
|
30-Jul-2010 |
Vasu Nori <vnori@google.com> |
random but useful stuff
1. move binding of args to one place - to SQLiteProgram
2. reduce locking time in SQLiteDatabase
3. reduce locking during time of binding of args
4. rmeove test for the deprecated ArrayListCursor
5. a couple of nits here and there
Change-Id: I20c33c8ffe3325df67af655f1d20614f7f727cb7
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 65a8883f0e605bb8a73a692987b47ce5da632e72 |
|
17-Jul-2010 |
Vasu Nori <vnori@google.com> |
don't store mDatabase in SQLiteCursor as it is already in SQLiteQuery
SQLiteCursor has two members: mQuery, mDatabase
but mQuery already has mDatabase.
there is no need for SQLiteCursor.mDatabase.
and everytime SQLiteQuery.mDatabase is to be used, try to use a pooled database
connection handle, if possible.
Change-Id: I42b2376d714a1a4091c843e245a45b882bb7fee6
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 6188c2746d0211985c5a656442c92b591dfdfd2a |
|
25-Jun-2010 |
Vasu Nori <vnori@google.com> |
remove some not-so-useful-logging
the sql statement is already printed if SqlStatements is set to VERBOSE
anyway. so no need for this extra logging
Change-Id: Id0e6c5acbbbd453ea45f08bcb802213bc22896fc
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 1a3b3d48413d9134738c9b457292fb2b71a5dfe4 |
|
13-May-2010 |
The Android Open Source Project <initial-contribution@android.com> |
merge from open-source master
Change-Id: I51b4eccfde8e74c69ab8e0c051bb8ea718ee7101
|
| f3ca9a5c7e87319c934b5815566054d2e5c2085f |
|
13-May-2010 |
Jeff Hamilton <jham@android.com> |
Add some documentation about the thread safety of Cursor and some of the SQLite* classes.
Change-Id: Icae51052d1c942d7d60bb958d3703411da001079
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 722802e76b8805da523a612ad3482450fd327db0 |
|
24-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Log database lock contention as well (as seperate pseudo-queries).
This also makes the 500ms logging threshold (over which is always
logged, and under which is sub-sampled) configurable via a
SystemProperty, which is mostly useful for interactive debugging when
lock contention is suspected, but could also be useful in the future
as a quick way to adjust this threshold for dogfooders, without code
changes.
Change-Id: I769069d8d870331d89a4aa3239ba50db806fe4d4
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 6a353876178ca2fe4bc61f128130067d2c2574d1 |
|
12-Feb-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Measure walltime in ContentResolver and SQLiteDatabase operations logging.
The forgotten parts from Id72f718c / d72f718c9c. Whoops.
Tested by watching a device's logcat -b events and observing no huge
or negative values. And this time with the right system.img file,
even!
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.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/SQLiteQuery.java
|
| 12311959c6ec6898e3b40d4e8958b29ec0b72da9 |
|
23-Nov-2009 |
Dan Egnor <egnor@google.com> |
Expand db_operation logging to prepare for widespread sample collection:
- always enable the log, but subsample for queries faster than 100ms
- add information about whether it's blocking a main thread
- log the entire sql (have not yet added quoted-string-stripping)
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 5a03f36ef845f73eb4473193dbb0f93dd12a51af |
|
21-Oct-2009 |
Vasu Nori <vnori@google.com> |
maintain cache of statementids returned by sqlite upon compiling a sql stmnt
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 935ae463d495d41155e27feb849768ad2b8b16db |
|
14-Apr-2009 |
Dianne Hackborn <> |
AI 145994: Integrate #145778 from Donut.
Automated import of CL 145994
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 4df2423a947bcd3f024cc3d3a1a315a8dc428598 |
|
05-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@136594
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.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/SQLiteQuery.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/SQLiteQuery.java
|
| d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/database/sqlite/SQLiteQuery.java
|