Thank you for your comments.
>> Karl Tomlinson wrote:
>>
>>> One thing I'm trying to understand is whether there was a reason for
>>> SQLite choosing to use a rollback journal (of the steps to undo a
>>> transaction) rather than a replay journal (of the steps to perform a
>>> transaction).
I didn't make this quite clear. I really meant, as a first
possibility, that writing the pages to the database itself would
be performed during the commit process after syncing the replay
journal (but the database need not be synced until the journal is
about to be removed).
In this situation, the replay journal would merely contain the
steps to _re-perform_ a transaction on recovery from filesystem
interruption (in much the same way as a rollback journal is used).
This makes the following easier to implement:
> On Jul 2, 2008, at 10:56 AM, Igor Tandetnik wrote:
>
>> begin;
>> insert into mytable values ('xyz');
>> select * from mytable;
>> end;
>>
>> I would expect the select to include the row I've just inserted.
There is also the option of not writing to the database
immediately (and possibly even not syncing the journal
immediately if durability is not required).
>> But with your scheme, the record is not in the database, but is
>> still sitting in the replay journal.
Yes, this scheme would require maintaining a buffer of page
numbers in the journal as D. Richard Hipp describes:
> SQLite would have to keep track of where in the replay journal each
> new page was written, so that if it needed to reload that page for any
> reason, it could. As long as the transaction (and thus the replay
> journal) is not too big, this is not a problem. A hash table in
> memory would suffice. But sometimes transactions do get very large.
> For example, with the VACUUM command. And in those cases, the amount
> of memory needed to record the mapping from pages to offsets into the
> replay journal could become too large to fit into memory, especially
> in memory-constrained devices such as cellphones.
The size of the transaction would be something to consider in the
decision on when to sync the journal and write its pages to the
database.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
