Two possible solutions::
a.) If you create a new database, check if a journal file with the right name exits already and delete it.
b.) When you create a new database, calculate a hash of some pseudo random sources like current date and time and current pid and store this id in the database. Copy this database id to every journal file you create in action of an transaction on this database.
Before you rollback a journal file, compare the database in the journal file with the id of the database file itself.
It must not be bulletproof. Just reduce the chance to a ratio like 1/(2^32 )or something.
Another one:
c.) Additionally use a "transaction counter". When a new database is created set this counter to 0. If you start a transaction, copy the counter value to the journal. If you apply a journal, make sure the database id and the transaction counter matches. After the journal is applied, increment the counter on the database, so the next journal will get a new transaction nummber. (Incrementing the counter on the database must somehow be part of the transaction itself.)
Solution a.) fights wrong journals orginating from other databases, solution c.) fights old journals on the current database.
Well, that's basically what I was going to say. So maybe you saved me having to do it. I didn't reply to say that earlier, because I thought of researching and giving a bit more detail in my answer.
That said, taking your answer as a point of departure ...
I am assuming that the added "pseudo random" data is stored in the header page. I am also assuming it is the paging layer that implements this stuff, as it does transactions, locking, and integrity too.
We are probably assuming that the journal file does not backup the header block of the main database file, since they have to by updated/synced independently. If the header does need backing up, then we may need to change things.
Or alternately, we may designate file page 1 to contain nothing but the new random data and leave the header alone at all times.
I suggest that B and C could be combined such that only the random number is stored, and that it is set/changed with the start of every transaction. The "random" number essentially should be a "unique id" for a database version among all other versions of the same database or of other databases. I suggest a value at least 64 bits long, or perhaps 256 bits long. This value would be copied to the current journal.
This corruption prevention/detecting process will require making and syncing a change to the core database file before making the journal file.
Here's a possible procedure, which lasts just during the time of an EXCLUSIVE lock, more or less; it just describes writer actions. Note that this can be amended to take place over the RESERVED lock instead if necessary; substitute the word then in my description below.
1. When there is no EXCLUSIVE lock in place, the <unique id> in the main file header is set to zero/null. Any process that sees this can assume that no journal file is supposed to exist; if one does exist, it is simply deleted. If this value in the main file is non-zero, and a journal file either doesn't exist or has a different number, then we know the main file may be corrupt. (Perhaps store a second flag to get around this?) As soon as a process is granted an EXCLUSIVE lock, it checks that this is so.
2. A new <unique id> is generated and stored in the main file header block, and that block is synced to disk.
3. A new journal file is created, the same <unique id> is stored in its first block, and that is synced to disk.
4. As per usual, any changed pages are flushed to the main file and synced, but first the old copies are backed-up to the journal and synced.
5. If we have to do a rollback, then write the journal pages to the main file and sync (but don't change the header block).
6. Change the <unique id> in the main file to zero and sync.
7. Delete the journal file.
8. Then the EXCLUSIVE lock is released.
That's a rough idea.
Ultimately, these suggestions are meant to protect against anything a common user can do, which means adding, renaming, moving, or removing files, at any time, and those files can have any file names.
-- Darren Duncan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
