summaryrefslogtreecommitdiff
path: root/graphics/java/android/renderscript/Script.java
diff options
context:
space:
mode:
authorVasu Nori <vnori@google.com>2010-07-04 00:26:18 -0700
committerVasu Nori <vnori@google.com>2010-07-07 15:33:42 -0700
commit2827d6d974beabb12344040a002dcb52dd7106b5 (patch)
tree43b09fea04bda6c0935470826b47bbc58bb59d49 /graphics/java/android/renderscript/Script.java
parent7fbee2f73e5ed8760b9f263a67fc21bcc3d367b1 (diff)
for WAL to work, can't keep prepared SQL stmt_id in SQLiteStatement
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
Diffstat (limited to 'graphics/java/android/renderscript/Script.java')
0 files changed, 0 insertions, 0 deletions