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
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
All these methods promise to do nothing
if the requested column is not present,
but in fact throw exception.
Change-Id: I0e528d53a0425b831b0083ba82c75ba5b41bfdfd
fixed a bug in SQLiteDatabase.isDatabaseIntegrityOk()
and added a new class to demonstrate use of
android.database.DatabaseErrorHandler
and a bunch of nits
Change-Id: Ia81870853fa3bd84074637f6d823a9fd22b66c7e
Now you can filter the count statement with a selection
and selection args
UnitTests for this new methods are added to the cts project
Change-Id: Id9233aec0eaac08839041ae7cbaba203470ad3d8
This depends on a kernel patch that implements read(2)
in the ashmem driver.
Bug http://b/issue?id=2595601
Change-Id: Ie3b10aa471aada21812b35e63954c1b2f0a7b042
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
this should help developers figure out what various sqlite errors mean
and possibly programmatically handle them.
Change-Id: I5c313be1b17b6c5171929bf04e19a16ea92bb357
Merge commit '4d5443762bd2b44b28edc2f2f75728911d70eac1' into gingerbread-plus-aosp
* commit '4d5443762bd2b44b28edc2f2f75728911d70eac1':
COMMENT ONLY change to clarify ContentProvider documentation.
Merge commit '86c035f0d176be9cb06b1e4f2390c25701417586' into gingerbread
* commit '86c035f0d176be9cb06b1e4f2390c25701417586':
COMMENT ONLY change to clarify ContentProvider documentation.
Gets a little more specific about thread behavior, and makes
pointed comments about not doing too much work in onCreate().
Change-Id: I682f0eb7d7559babee901ed26642751a6ba0a1ea
1. SQLIteStatement.executeUpdateDelete() replaces execute() - and returns the
number of rows changed.
2. let SQLiteDatabase.execSQL() call the above new API - which
means all CRUD statements by execSQL() are stored in prepared statement cache.
3. remove the following from SQLiteDatabase
lastrowId
lastchangecount()
native_execSQL()
Change-Id: I4e93a09dc381f425c3ae6ccc331a7bf227491e22
seems this stuff is not used at all. a couple of CTS tests fail due to this code
not being corrected after recent changes to disable updates through cursor.
Change-Id: Iba87258e1c8fa18c2cc46d1d2ab56ec3e38413f2
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
music2 app has the weird situation where it embeds the jumper C++ code
and that code uses its own version of sqlite.
so, java side may want to disable WAL to make c++ code work well with java
usage of sqlite.
since WAL is made default option for all apps, this CL makes it possible for
music2 app to disable WAL.
Change-Id: I39ddbc9b4648f12b206ff3e76d30341da5955bd4
Now, when Thread A has a strict mode policy in effect and does a
Binder call to Thread B (most likely in another process), the strict
mode policy is passed along, but with the GATHER penalty bit set which
overrides other policies and instead gathers all offending stack
traces to a threadlocal which are then written back in the Parcel's
reply header.
Change-Id: I7d4497032a0609b37b1a2a15855f5c929ba0584d
This allows you to define a callback in Java that can be called from
sqlite3 database triggers.
Change-Id: I09fdbd38c9807b6b0dd19c2761b01e8db76f1adc
Signed-off-by: Mike Lockwood <lockwood@android.com>
Do compiling of sql, binding of args and execution of the SQL
statement within one single database lock period.
This reduces the number of times the database lock
needs to be acquired during the course of compilation, binding
and execution of a SQLiteStatement.
Change-Id: I22b090ec9e10fc0aa2532a93bafe610af2546b58
apps should not setting journal_mode if the application is
using a connection pool for readers by calling the method
SQLiteDatabase.enableWriteAheadLogging()
Change-Id: I9ddb32638171c6277ca94381a1b5d4b39b92b386
Some (including the Contacts app) do the following:
1. Open database
2. As part of database_connection.onCreate(),
Create some SQLiteStatement objects to cache them in the process
3. attach databases
WAL doesn't work with attached databases. so, apps doing the above
should enable WAL only if there are no attached databases.
But we would like to enable WAL automatically for all apps after step #1 above
and disable WAL if the app subsequently does 'attach database' SQL.
this works only if there are no SQLiteStatement objects created in step # 2,
because SQLiteStatements cwmaintain a hard-reference to the database connection
for life and also to the prepared SQL statement id.
It is quite difficult to disable WAL in step # 3
if it is enabled in step # 1
and then a connection pool gets used by step # 2
would make WAL disabling easier if SQLiteStatement refers to prepared SQL
statement id only when it is needed (during binding and execute calls)
and thus NOT tied to a spacific database conenction.
also, from the standpoint of not blocking readers, it helps NOT to have
SQLiteStatement be married to a database connection and prepared SQL statement
id for life.
Change-Id: I464d57042965a28d2bde88e0f44b66ec119b40dc
this method causes sql statement in a SQLiteProgram object to be never
re-compiled. thats not desirable, is it?
there should be no need for this method.
Change-Id: I207fad6415c1e2ef4097ee65a3ff347b5435b994
