On Jun 20, 2009, at 12:06 AM, Robert Lehr wrote:
> I finally got around to reviewing SQLite's asynchronous I/O
> functionality.
>
> http://sqlite.org/asyncvfs.html <http://sqlite.org/asyncvfs.html>
>
> We actually have an C++ wrapper to uses the same concept, a
> background thread for I/O.
You mean you have implemented the callback methods in struct sqlite3_vfs
to read and write asynchronously just as we have? Or some other
technique?
> The async functionality included w/ SQLite is not a complete
> replacement for ours, though, although it would be convenient to do
> so. However, we do things differently such that we
> cannot take advantage of SQLite's async functionality.
>
> * We queue transactions, not individual queries. Note that,
> because queue
> transactions_ instead of queries, we lock the database per
> transaction,
> thus avoiding the reduction in concurrency that is described on
> the async
> I/O page.
>
> * Our bg thread implementation retains durability by permitting
> registration
> of callbacks for queries' successssul completion and aborts.
>
> W/rt to the locking policy w/ multiple updates, are there design
> reasons for
> not releasing and re-acquiring a lock between transactions? That
> would facilitate
> higher concurrency albeit it a slightly higher cost than the current
> implementation.
> That cost should match the current cost of multiple transactions,
> though.
It's to handle this:
BEGIN;
UPDATE t1 SET <stuff> WHERE <condition>;
COMMIT;
BEGIN
UPDATE t2 SET <morestuff> WHERE <anothercondition>;
COMMIT;
If the SQLite user starts the second transaction before the asynchronous
thread has had time to commit the first, it will read the database to
figure out the set of rows to apply the <morestuff> modifications to.
Once
that has happened, the database file cannot be unlocked before the
second
transaction is committed. Otherwise, some other client might sneak in
while
the database was unlocked and modify table t2, changing the set of rows
<anothercondition> selects.
Of course, if the asynchronous thread manages to commit the first
transaction
to disk before the user has time to execute the second, the database
file
will be unlocked between transactions.
Dan.
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
