On Fri, Feb 25, 2011 at 12:04 PM, Dan Kennedy wrote:
> On 02/26/2011 12:30 AM, Johns Daniel wrote:
>> What is the reason was for having random filenames for the SQLite
>> master journal file (like mine.db-mj501CA440, mine.db-mj1C17,
>> mine.db-mj66677495, etc)?
>>
>> Here is the reason for this strange question. We have discovered that
>> the JFFS2 filesystem in Linux is leaking kernel memory each time we
>> open/close/delete a file with a different name! I have not figured out
>> how to fix the leak in JFFS2 yet. I was wondering whether this
>> workaround is safe: Change our SQLite code to always use a fixed
>> filename (like mine.db-mjMASTER).
>
> The problem is that if a crash occurs during a multi-file commit,
> the master journal cannot be removed from the file-system until
> the transactions have been rolled back for all database files.
> And this doesn't happen until the first time each of them is
> read.
>
> For example, say you have two databases in a transaction - mine.db
> and yours.db. A crash happens while committing the transaction
> and the file mine.db-mjMASTER is left in the file-system.
>
> Following recovery, if a process tries to read mine.db, the
> transaction on mine.db will be rolled back. But the master
> journal file cannot be deleted yet (since the interrupted
> transaction on yours.db has not yet been reverted).
>
> If the process then attaches "ours.db" and then tries to
> write a multi-file transaction that involves mine.db and
> ours.db it has a problem - it wants to create and populate
> mine.db-mjMASTER but it cannot, since that file is still
> in use.
>
> We use the random names to get around this problem.
> You could probably get away with using "-mjMASTER1",
> "-mjMASTER2" etc. if you wanted to. See the loop around
> line 1729 of vdbeaux.c.
>
Thank you very much for this info, Dan! Very useful.
>From your description, it sounds like this requirement only applies if
there are 3 or more databases. Is this an issue with 2 databases?
We have 2 databases. We open one and attach the other one to it at the
very beginning of our single (multi-threaded) database process.
Subsequently, we starting issuing SQL statements that could affect
either one or both databases. It seems we could get by with a single
master-journal filename. Do you agree?
-- Johns
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
