On Thursday, January 13, 2011 7:55:28 pm Pavel Ivanov wrote:
> What you really want is for database engine to allow to have two
> parallel writing transactions and for it to not lock the whole
> database in those transactions but do some fine-grained locking
> instead.
Well, that would work, but what I need is far simpler.
Sqlite today has savepoints which I interpret as recursive transactions. As a
consequence of savepoints, sqlite already knows the boundary between multiple
savepoints. I suppose they are implemented as copy-on-writing pages that have
been copy-on-writed themselves.
Example:
insert 1
savepoint A
insert 2
rollback to A
so "savepoint A" means that further changes should go into a different set of
copy-on-write pages. "rollback to A" then undoes "insert 2" by discarding
those COW pages created by "insert 2" but keeping the COW pages created by
"insert 1".
So, similarly, one could implement "commit to savepoint A" by taking the COW
pages created by "insert 1" and committing them to disk, but keeping the COW
pages created by "insert 2" uncommitted.
I suppose hypothetically, I could get what I want (with a huge performance
penalty) by just keeping a list of the actual SQLite statements I made
represented by "insert 2" above, doing a rollback to A and a commit, then
replaying those "insert 2" statements. That way I can continue to make sqlite
queries on data that isn't going to be committed at the next checkpoint.
However, this would perform a lot more poorly then doing it at a page level.
Charles
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
