On Jul 2, 2008, at 10:56 AM, Igor Tandetnik wrote:
> Karl Tomlinson <[EMAIL PROTECTED]>
> wrote:
>> I've done a little looking into journals, fsyncs, and filesystems
>> recently.
>>
>> 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).
>
> It seems to me that with a replay journal, it would be rather
> difficult
> to make this work:
>
> begin;
> insert into mytable values ('xyz');
> select * from mytable;
> end;
>
> I would expect the select to include the row I've just inserted. But
> with your scheme, the record is not in the database, but is still
> sitting in the replay journal.
>
Right. In order to get transactions like the above to work correctly,
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.
Keeping track of changes is not a problem with a rollback journal, you
will notice. The current value of any page can always be obtained
directly from the database file using the page number to compute the
offset.
D. Richard Hipp
[EMAIL PROTECTED]
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
