SQLite Notes

Execute statement

Every statement has an associated connection object, a statement represents a single ‘compiled’ SQL statement. There’re two methods to execute SQLStatement instance in AIR, one execute a single statement each time, another use .begin() .commit() to execute multiple statements, as a transaction. For SQLite engine, they both transaction, the single statement operates in autocommit mode by default.

SQL statement execution process: Statement+SQL -> Compilation -> Byte Code (with parameters) -> execution -> Finalization

Use parameters for statements is highly recommended. One important benefit Adobe might not documented: SQLite takes care of escaping the string values binding to parameters, helping avoid syntax errors and SQL injection attacks, i.e, it will convert ‘ to ”.

Transaction and Locks

  • Multiple read transactions (SELECT), one single write transaction (INSERT/UPDATE/DELETE) at a time.
  • When write transaction is writing (exclusive locked), no new transactions can connect.
  • Write transaction will wait for any running read transactions to finish before writing.

Each transaction (or SQLStatement execution in autocommit mode) transit from one state to another state.

A default SELECT statement run in path as followed: Unlocked -> Pending -> Shared -> Unlocked

Two SELECT statements grouped with .begin() and .commit() in a single transaction:

Unlocked -> Pending -> Shared -> Unlocked

Two SELECT statements run in turn:

Unlocked -> Pending -> Shared -> Unlocked -> Pending -> Shared -> Unlocked

A write transaction (i.e. UPDATE) by default (autocommit mode):

Unlocked -> Pending -> Shared -> Reserved -> Pending -> Exclusive locked(commit) -> Unlocked

A write transaction with ‘BEGIN IMMEDIATE’:

Reserved -> Pending -> Exclusive locked(commit) -> Unlocked

The ‘Reserved’ state is a tricky state that may a place to improve performance. It actually store modifications in a memory cache, and create a rollback journal file for possible crash recovery. In this state the write transaction get real work done without affecting other read transactions. That’s how ‘multiple reader, one writer’ works.

After the write transaction get it work done, it begins trying get a Pending lock to move to Exclusive commit state, where (Pending) no more new read/write transactions (they have to wait in queue), the write transaction need to wait any other transactions still working to finish. Only after anything else cleared, this transaction enter into Exclusive state.

The ‘Exclusive’ state is to flush the modifications from cache to database file.

SQLConnection has a property cacheSize that affect write transaction. In ‘Reserved’ state if page cache fills up, it have to move to ‘Exclusive’ state before finish its own task. The bigger cacheSize the more modified pages can store and minimize the time to be used in ‘Exclusive’ state. (sqlite_analyzer can dump detailed statistics helpful for adjusting cacheSize)

3 Comments so far »

  1. Jens Wegar said

    am February 8 2009 @ 1:11 pm

    Hi,

    Since you seem to know some about transactions in SQLite and AIR, I have the following question that I hope you can answer:

    Is it possible to have a SELECT statement after a INSERT or UPDATE statement in a transaction?

    Reason I’m asking is I have a application where I can edit and insert items to a datagrid. Inserting new items happens through copy-pasting from the system clipboard, after which I would like the datagrid to update to reflect the change. But if I put both the INSERT and SELECT statement in the same transaction, my application crashes. The insert get’s run though, because the item is in the list if I relaunch the application. If I remove the SELECT statement, the application works (i.e. doesn’t crash). Any thoughts?

  2. george said

    am February 8 2009 @ 10:47 pm

    You can have INSERT(write) and SELECT(read) statements inside a single transaction (use begin and commit).

    If your connection in asynchronous mode, you have to wait first statement complete, then execute next statement.

    Be careful on locks.

  3. Jens Wegar said

    am February 9 2009 @ 10:03 am

    Thanks for the reply. I’m guessing my issue is because I’m using asynchronous mode and perhaps the first statement (write) does not complete before the second statement (read) is run. I’ll try with refactoring the code so that I make sure to do the read operation only after the write has completed.

Comment RSS

Leave a comment

Name: (Required)

eMail: (Required)

Website:

Comment: