b773312982bca3715015211c7e7c5c4d17687e60 |
|
25-Jul-2017 |
Fyodor Kupolov <fkupolov@google.com> |
Tests for lookaside configuration Test: android.database.sqlite.cts.SQLiteDatabaseTest Test: android.database.sqlite.cts.SQLiteOpenHelperTest Bug: 63998707 Change-Id: I2e84a6e98baf889001ef7537a290f7e2aa2d709a
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
baefdfad6e77e772deb6474380dd85ac776293e8 |
|
05-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Make SQLiteDatabase final. The SQLiteDatabase constructor is inaccessible so it is not possible for applications to subclass it. To remove all possible remaining temptation to do so, make the class final. Change-Id: I4148e9b06f0661ec22aab8e45afde38498d2375a
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
638eff7ee10ea16b5eabc56411a6609355cd8243 |
|
01-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Improve documentation of SQLite debugging options. Change-Id: Id3b4d9e4e9dd62d2a1e6188477225af7717788f4
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
4b57553e693c9705e8363d3e0e9d881261b3e6fa |
|
20-Jan-2012 |
Jeff Brown <jeffbrown@google.com> |
Initialize SQLite as part of the android runtime. This ensures that the SQLite library is always correctly configured and initialized before other framework or application code has a chance to use it. This is important because initialization has to happen at most once so we need to get it right and prevent races. This change makes it possible to omit the SQLite auto-initialization workaround from the SQLite library, potentially saving a few cycles here and there. Change-Id: Ifbed8685ee44aa1e9c0b391e233b0257fa738e4f
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
254fba8960b018a29c5fe422b8a0fd9eeedbf3e4 |
|
20-Jan-2012 |
Jeff Brown <jeffbrown@google.com> |
Clean up SQLiteDebug natives. In particular, ensure that the database is initialized. Change-Id: Ifa69a9dfa9d008af79beadbd1a25e90d0d29e66c
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
2a293b61cb0efbf24994d74ed980f58b820bb35a |
|
19-Jan-2012 |
Jeff Brown <jeffbrown@google.com> |
Clean up SQLite debugging code. Deleted a bunch of dead / useless code. Raised number of logged operations in dumpsys dbinfo to 20. Change-Id: I88344ff57a978f200c1f0172141d91e430caa1a9
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
a9be4154e8dac0de3db5ee42e878beb0639e70e6 |
|
19-Jan-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix issues with reentrant SQLite triggers. Modified SQLiteConnection and SQLiteSession to support reentrant execution of SQLite operations, as might occur when a custom function is invoked by a trigger. Bug: 5884809 Change-Id: I253d828b2801bd06b1bbda7caa7da3f040a642bb
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.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/SQLiteDebug.java
|
6754ba24f12a54b97b3ca1c5d29fc23c15980abe |
|
15-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Add plumbing for dumping database info using dumpsys. Change-Id: I51b0364c3d3d41aa38a759fbce48e625fff1b2dd
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
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/SQLiteDebug.java
|
00e40171892c73295b6e7221ed83126731230b98 |
|
29-Nov-2010 |
Vasu Nori <vnori@google.com> |
Revert "Merge "print certain rows from downloads.db when bugreports are taken"" This reverts commit 34878787f06c07b5cf14879254ef9abccffa631b, reversing changes made to 5a2755d0c9220b6bc52cb1262927e27dc3dce6c1.
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
624002b0d5b5bd812ca457fdfde0ead2b908eb7a |
|
22-Nov-2010 |
Vasu Nori <vnori@google.com> |
print certain rows from downloads.db when bugreports are taken when downloads fail/get stuck, we need to look at the database state for those downloads. and when the users report such problems, it is a royal pain not to have that info and most users don't seem to bother sending database dumps because it is a bit of work. so lets just dump info about downloads that failed or downloads from GSF (OTAs, for example) helps debugging. there is STOP ship comment to not dump data once HC is released. Change-Id: Id1254982fd82b4c55f1816a2491f00966840f024
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
b57f85bc5b47ff8e8fa1e8bd153331cdc4794713 |
|
28-Apr-2010 |
Vasu Nori <vnori@google.com> |
am 6813f8d2: am 785c8983: am 996960de: Merge "remove myname accidentally included in one of the files" into froyo
|
0f43f2f70070051e32c8687fd79da3acd6bcfe62 |
|
28-Apr-2010 |
Vasu Nori <vnori@google.com> |
remove myname accidentally included in one of the files Change-Id: I189db1cc60069b4318fa32a8b5aea6916ac5aa4e
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|
90a36726b7553a1e7efd2f4ecbe01d7e1b3e7a67 |
|
12-Apr-2010 |
Vasu Nori <vnori@google.com> |
let apps set statement-cache size. 1. we should let apps set their statement-cache size. right n ow it is 250 is the statement-cache size for all apps and that is wasting a lot of memory. each prepared statement is averaging about 1k-5K, depending upon the complexity of sql and schema. mnake default 25 and let apps increase the size, if they need to. 2. in "adb bugreport" info, print stats on the statement-cache hits/missies and size (in number of statement cached). this will help us understand how statement-cache is being used Change-Id: Ic53a2842ef75823757492778158fcb8d5b4a28bb
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.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/SQLiteDebug.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/SQLiteDebug.java
|
4dd4ab4cc322e82401f380aeb877daa4a20d7069 |
|
30-Jan-2010 |
Vasu Nori <vnori@google.com> |
add instrumentation to log the sql statement + bindargs + databasename capture the sql statement along with the bindargs passed in. this will help one to see the sql statements being executed and hopefully will help debug incorrect-sql bugs.
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.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/SQLiteDebug.java
|
c4516a7b62de525e3d6d5e76851bdfaf12c11f05 |
|
03-Sep-2009 |
Fred Quintana <fredq@google.com> |
add a transaction monitor
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.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/SQLiteDebug.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/SQLiteDebug.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/database/sqlite/SQLiteDebug.java
|