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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users