It seems to me that the biggest worry about nested transactions is backwards compatibility. So, first, let me reiterate some points:
1). Actual changes to the database occur thru only one user at a time and modify the database directly. 2). The journal is created by this one user and is a record of how to put modified database back to its original state. 3). If the process/computer dies, upon reading the database, if a journal is found, the database is restored. So, now, it seems to me that to handle nested transactions while maintaining backward compatibility you'd: 1). Leave the name of the current journal alone, it will represent the lowest or first transaction. 2). Upon first read of the database, if this journal exists, do what it currently does, restore the database using only this journal. This maintains backwards compatibility. 3). Upon start of a new transaction, create a new journal, perhaps journal1 then journal2 and so on. It will record changes to the database just like the current journal does. 4). If this transaction commits, nuke the journal, its no longer needed. 5). If the transaction is aborted, apply it just like applying the journal of the base transaction. Internally, you'd need to keep track of the transactions in a list/stack with their associated journal name. Now, with all that said, I can't say how much work it would take to apply this kind of change, but conceptually it doesn't seem all that hard. Any takers want to debate this? -- Joel Lucsy "The dinosaurs became extinct because they didn't have a space program." -- Larry Niven
