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.
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.
Many thanks.
-robert
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
