The current error message says "close failed due to unfinalised statements".
This CL fixes that message by incorporating one of the un-closed sql statements
should help developers debug the problem.
Change-Id: I2a24c6ba876caa008507b236052c5f03e8cbb27e
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
The signatures of the existing buildQuery and buildUnionSubQuery methods include a selectionArgs
parameter that is not actually being used in the method implementations. This parameter leads
to the misconception that SQL paramter substitution is carried out by these methods. I added
new variants of these methods without that parameter and deprecated the old variants.
Change-Id: I1bf770d5c777649e9aac36d93aa93bd65bbcc2a3
This warning doesn't really matter much. If a developer wants to
debug the cache usage, it can be done by turning on this flag.
adb bugreport also displays cachestats - which can be used as a debugging tool.
Change-Id: Ied173714d535c271133247ee4768f86d3be359cf
the warning printed currently "do requery on background thread"
is not that useful in processes such as gapps, acore.
to reduce the deluge of bugs assigned to me, I think a simple
deprecation warning is better.
Change-Id: I7a1129ea889f10e72895092a3cdd48cc96d0d1f0
Make clear in the Javadoc comments of the `Cursor` get* methods that
implementations thereof can have implementation-defined behavior. In some cases,
these changes actually correct the documentation. For example, in the case of
`getShort` and the `SQLiteCursor` implementation thereof, non-numeric data is
*not* converted to a `short` via Short#valueOf or even in a functionally-
equivalent manner.
Change-Id: Ib2f81811a603680b52fc482eb9c0f3195447566f
In two places involving locking, reordered the code so that the lock
acquisition is performed outside of the `try` block and everything
else that needs to run while the lock is locked *within* the `try`
block.
Change-Id: I3dad2c4bbf60b219fc6db2aa35e2ed296cb39128
database lock() should not be called from a synchronized methods
in database layer. add code to check.
this will catch potential deadlock situations sooner
Change-Id: I9d913f5e2af304f4d9ad5b2641c3a768c4bc97f9
This makes it more future-proof and maintainable, not exposing the
internal bitpacking state.
The implementation is unchanged (the policy is still just an int we pass
around).
Also starts to introduce VmPolicy, for things which are process-wide,
not per-thread. As an initial user, make SQLite's Cursor finalization
leak warnings use StrictMode.
Change-Id: Idedfba4e965716f5089a52036421460b1f383725
Synchronized blocks should never call lock() or any operation that
does it. otherwise, bugs like bug:3032897 will occur.
Remove synchronization on all methods in SQLiteStatement
and SQLiteProgram because the caller is supposed to
do the synchronization if the same SQLiteStatement or
SQLiteQuery (which extends SQLiteProgram) object
is used by more than one thread at the same time.
(documentation on SQLiteStatement, SQLiteProgram
mentions this note)
Change-Id: Ifd6ee94d743c38c187e2eb778c57076da7a15073
Merge commit '173ea0912af296c6e80d14b764046534b316d21f' into gingerbread-plus-aosp
* commit '173ea0912af296c6e80d14b764046534b316d21f':
DO NOT MERGE - use appropriate names on SQL numbers in 'adb bugreport'
connection pool = number of database connections opened when the app opens
a database. These pooled connections are used by readers only and they
use the sqlite write-ahead-logging option to increase reader
concurrency.
The size of this connection pool depends on the number of CPUs, RAM etc.
On most single-core devices, this can be set to 1.
But on some multi-core devices with more RAM, pool size can be
more than 1.
On a device with more resources, here are the results of a test (in
coretests/src/android/database/sqlite/SQLiteDatabaseTest.java)
which measures the reader-parallelism achieved for different connection
pool sizes.
connpool-size = 1
num xacts by writer = 467
num-reads-in-xact/NOT-in-xact by reader1 = 1358/14542, by reader2 = 1431/14269
connpool-size = 2
num xacts by writer = 473
num-reads-in-xact/NOT-in-xact by reader1 = 5703/35227, by reader2 = 6222/35898
connpool-size = 3
num xacts by writer = 542
num-reads-in-xact/NOT-in-xact by reader1 = 6531/32329, by reader2 = 6252/32728
connpool-size = 4
num xacts by writer = 578
num-reads-in-xact/NOT-in-xact by reader1 = 6009/32701, by reader2 = 5977/32953
connpool-size = 5
num xacts by writer = 547
num-reads-in-xact/NOT-in-xact by reader1 = 6554/31186, by reader2 = 5318/31022
connpool-size = 6
num xacts by writer = 534
num-reads-in-xact/NOT-in-xact by reader1 = 5317/31463, by reader2 = 5413/31537
connpool-size = 7
num xacts by writer = 549
num-reads-in-xact/NOT-in-xact by reader1 = 5396/28004, by reader2 = 5214/28496
seems like connection pool size of 3 is optimal on this device.
Change-Id: I348ff5a31783c31b5e3e5ac78b7c2cea54ef114a
SQL statements such as Create table, Pragma, Begin, Commit, Rollback
etc don't need a compiled statement.
Change-Id: I55f5e4e6cbb41cbe83e592e25ba852fe23e2b39f
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
1. when LRU cache wants to remove the eldest entry, it may be finalizing
a statement that is still in use
2. a couple of synchronization issues.
3. a bit code refactoring in SQLiteCompiledSql
4. remove a bunch of unsed debug code from SQLiteDatabase
Change-Id: I45454dc2dbadd7d8842ba77dd2b0e9ff138ec6f4
it is confusing to figure out where the debug messages are coming from.
this TAG value change helps
Change-Id: I3a6f445fbced4a962cc13dbb8dd1d7968f9aec9d
1. let execSQL() methods return the number of rows affected by the SQL
staement executed.
2. remove synchronized on 2 public methods. since public API is not
supposed to have synchronized, this was a mistake in previously submitted
CL
Change-Id: Ic610a0c38e7bd7c77006a08c7b82fa01957739e5
1. Moved all code related to compiled-sql statement cache to SQLiteCache.java
Removed all caching related code from everywhere else.
2. Moved all code related to compiling a sql statement and caching it to
SQLiteCompiledSql.java. There was some code in SQLiteProgram.java
releated to this. moved it out.
3. Added state to SQLiteCompiledSql. This is to help in debugging.
Change-Id: I63ab0c9c4419e964eb9796d284dd389985763d83
