History log of /frameworks/base/core/jni/android_database_SQLiteConnection.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
76f6a86de25e1bf74717e047e55fd44b089673f3 19-Sep-2015 Daniel Micay <danielmicay@gmail.com> constify JNINativeMethod function pointer tables

Change-Id: I4036c924958221cbc644724f8eb01c5de3cd7954
987f79f60bb1f0a4bcd3ef22e57301c743f0b94f 19-Nov-2014 Andreas Gampe <agampe@google.com> Frameworks/base: Replace LOG_FATAL_IF in core/jni

Do not use LOG_FATAL_IF in JNI setup. This is one-time on startup
and important enough to always check.

Add a header with common helper definitions. Move to inlined functions
instead of macros to clean up the code.

Change-Id: Ib12d0eed61b110c45d748e80ec36c563e9dec7e5
0f0b4919667f418b249c497f5ad3e83fdf4437e5 12-Nov-2014 Andreas Gampe <agampe@google.com> Frameworks/base: Wall Werror in core/jni

Turn on -Wall -Werror in core/jni. Fix warnings.

Clang TODO: For GCC we need to turn off Wunused-but-set-variable in
the GL bindings. However, Clang doesn't have that warning and thus
complains about an unknown pragma. It is necessary to make the
pragma #ifdef-ed on the compiler being GCC.

Change-Id: I14cab48d45c2771eef0432082356c47ed44a3d7f
738702d28ab7e0e89e3c6e18fd46cc1361917eb9 02-Jan-2014 Ashok Bhat <ashok.bhat@arm.com> AArch64: Use long for pointers

For storing pointers, long is used in CursorWindow
and SQLiteConnection classes as native pointers can
be 64-bit.

Change-Id: Ia686006a7b8bdc7b95e5de0d0a294b155034a921
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
87eac99a21772ae56018cb81db6966557b459554 10-Sep-2013 Ruben Brunk <rubenbrunk@google.com> Remove dependency on JNIHelp header side effects.

Bug: 10680559
Change-Id: I47870d6c48906e0a420c52b7bc5945ffe29c68a2
2a3b91846e73cf6917b50050206e10fafd0302b1 20-Dec-2012 Jangwon Lee <jangwon.lee@lge.com> Fix bugs regarding IllegalStateException during moving position in cursorwindow.

"startPos + addedRows < requiredPos" could miss a row in boundary position.
Because of the fluctuating row size, "startPos + addedRows < requiredPos" expression could miss a row in boundary position.
For example, simply speaking,
if window capacity = 120 and requiredPos = 120,
"fillWindow" needs to be newly called and "starPos" is 80 for the window.
Unfortunately 120th row is bigger than the rest size of the window,
the row for requiredPos is not in the window.
Then, startPos has to be newly set and the 120th row has to be included in the window.
But by the expression above "startPos + addedRows < requiredPos",
the row for requiredPos is regarded as included in the window.
In that case, by "mCurrentRowID = Long.valueOf(getLong(mRowIdColumnIndex));" statment in AbstractCursor,
IllegalStateException is thrown.

This patch contains modification of the expression as "startPos + addedRows <= requiredPos".

Change-Id: Iaee75241e495949b0a624b836843da18d0bcb98d
9d25fa67a9291d469fa4006b2a373c8429132536 05-Jun-2012 Jeff Brown <jeffbrown@google.com> Report extended error information from SQLite.

The error code number is not as informative as the SQLite error
message, in particular because the error code has been stripped
of extended error information. Make sure we ask SQLite for the
full error message whenever possible.

Bug: 6538393
Change-Id: I82457c0ff7e41659cf8195fa26e09dc2b467375e
676c519ec4509c799049bae5f6b20748ee5210c1 31-May-2012 Jeff Brown <jeffbrown@google.com> Increase busy timeout.

Bug: 6579925
Change-Id: I110d9a98479cbfcc518deef6d59b0f956396b6da
330ec91e02406ba0d62e5672c6f0e2ed271f6898 20-Apr-2012 Jeff Brown <jeffbrown@google.com> Check whether db was really opened read/write.

Bug: 6176510
Change-Id: I7aeeb4340e55d554a57bb46c3c27ab37186f7e3a
1d9f742e001ed8280fa93fd9ba0b1125ce6d00ae 15-Mar-2012 Jeff Brown <jeffbrown@google.com> Port the SQLite locale setting code to Java.

Make the database opening code more robust in the case of
read-only database connections.

Check whether a PRAGMA needs to be issues before doing it.
Mostly it's harmless but it can grab a transaction on the
database unnecessarily.

Change-Id: Iab2cdc96c785e767f82966b00597e19337163f2f
5936ff097eff2c736af2e43fd4a8f7db0ddcfb5a 01-Mar-2012 Jeff Brown <jeffbrown@google.com> Externalize more SQLite configuration options.

Moved more configuration into config.xml so we can tweak settings
like the default journal mode, WAL auto-checkpoint interval and
so on.

This change itself should not introduce any functional differences.

Change-Id: Id6c95fa25b116ce47e8ae49cd8a80d52b1c0dd80
958cbbab6a35e1668419a2f7e2a2b75b9c8db807 01-Mar-2012 Jeff Brown <jeffbrown@google.com> Don't throw if sqlite3_finalize returns an error.

Change-Id: Ibcc772ad5343dd241ed9dc492e4d838e1ab962d4
49d2b1864c3dfec6faff74d67cb2527a8f1af5a8 28-Feb-2012 Mathias Agopian <mathias@google.com> move CursorWindow from libbinder to libandroidfw

Change-Id: I3b304e4f74e0d0ec8b20c57296c62449c9a0f792
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
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