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
Merge commit '7e343b8d39309d2c9d73cc5d1ec2434e666ae48b'
* commit '7e343b8d39309d2c9d73cc5d1ec2434e666ae48b':
fillWindow's start position must be smaller than getCount value
the sql statement is already printed if SqlStatements is set to VERBOSE
anyway. so no need for this extra logging
Change-Id: Id0e6c5acbbbd453ea45f08bcb802213bc22896fc
- Move PackageInfo out of ActivityThread, renaming to LoadedApk.
- Rename some of the other PacakgeInfo inner classes to better
represent what they are.
- Rename HistoryRecord to ActivityRecord.
- Introduce AppGlobals, to eventually let ActivityThread become
package scoped.
Change-Id: Ib714c54ceb3cdbb525dce3db9505f31042e88cf0
an app can execute 'attach database..' statement anytime after WAL is
enabled. since WAL doesn't work with atatched databases,
disable WAL whenever the caller executes 'attach database'
sql statement.
Change-Id: I77dfcb744b59476c357d44296c14d63455985a7b
due to a bug in DefaultDatabaseErrorHandler, if the corruption is
so bad that the list of attached databases can't even be retrieved,
then database is not closed in DefaultDatabaseErrorHandler,
this causes the corrupted file to remain on disk.
this causes corruption detection to occur forever until the stack
overflows.
Change-Id: I9896bee220231cbde0b1620ad0a617420424967c
setting journal_mode to TRUNCATE on memory databases causes an error message
to be displayed by SQLIteDatabase.
Change-Id: Ie8b8ae22cb9fba99cee59dba35b260195c63eadc
two bugs were introduced by the above CL
1. to test if the column value is NULL, getType_native() should check if
the columnindiex is valid. (it seems sometimes callers could ask if a
given non-existent column is null - and the answer should be true.)
2. if a column is null and isBlob_native, isString_native methods should
return true - not false.
Change-Id: I64df75d0a3840a4502c00db8759c66ba4b268a26
cts tests are in Change-Id: Ifcc89b4ff484c7c810fd2d450ded212a43360dda
dependency on: Change-Id: I938c42afc3fb50f5296d01c55ffcf4a102d8b0cb
1. Use sqlite's work-in-progress writeahead logging feature to read old
versions of data and thus increase concurrency of readers
even when there is a writer on the database
2. New API executeQueriesInParallel() sets up a database connecion pool
automatically created and managed by sqlite java layer
3. To increase reader concurrency, add an option to do BEGIN IMMEDIATE xaction
instead of BEGIN EXCLUSIVE
Change-Id: I3ce55a8a7cba538f01f731736e7de8ae1e2a8a1f
sometimes the database can be so corrupt that it cannot even be queried
for attached database list.
Change-Id: Ib8fe3bd94157acab3fbf1011c3f8a532ef5019f4
SQLite is JNI to native code and doesn't go via IFileSystem, so it
needs custom sprinkling, at least for now.
Change-Id: Ic7fded1b64a4f483dfc17b3a7b136c803df1e111
add new method openOrCreateDatabase in Context.java to allow
callers specify a DatabaseErrorHandler object to be used when
database corruption occurs.
add new constructor in SQLiteOpenHelper to accept DatabaseErrorHandler
as an additional param to be used when SQLiteDatabase instance is
created.
Change-Id: I912a0202a74510f9ca0206dd8101c4abab9102ae
A change was made in the last CL to ask sqlite for all unfinalized statements
and then finalizing them before closing the database.
But this crashes sqlite! because sqlite's FTS3
module keeps some prepared statements around and they should not
be finalized before closing the database.
(when sqlite is asked for all unfianlized statements, it also returns
the FTS3's reserved prepared statements which should not be
finalized!!)
Change-Id: I141ab4563985b8cd1305a1228c4cb01bc7281bcb
bug:2683001
implmentation details:
1.close() on any sql statement is should simply queued up for finalization
to be performed later. caller doesn't acquire database lock.
2. the only effect of NOT close immediately is non-release of some memory.
3. all such queued-up-finalizations are performed whenever there is
another execute() of some sql statement on that database from ANY
thread in the process.
4. database close() automatically releases all unfinalized statements
before closing the database.
Change-Id: If4c9c7fde6b8945a41abc6c8b992aa8c69854512
it is trying to get attachedDb list (by executing a pragma) after closing
the database.
also added unittests.
Change-Id: I7dce665ec7354402cdef6fbe055455f5798e123c
