Hi!
>>>>> "Jan" == Jan Dvorak <jan.dvorak@stripped> writes:
Jan> Hi all,
Jan> I agree with Tim.
Jan> That's the way the 'big names' use
Jan> to ensure data safety.
Jan> I've always interpreted the MySQL team's
Jan> "we'll never support transactions" statement
Jan> as "we'll never support roll-backs".
Jan> It's a design choice I like;
Jan> in fact, most times I met a 'big names' database
Jan> I had to find my way around the roll-back feature,
Jan> because it really slowed the server almost to a halt.
Never say never; We have only said that we don't intend to
support transactions in the near future as we don't regard this is
very important. However, things has changed as we got an offer about
transactions that we can't easily refuse and because of this
transactions is now on the top of our TODO.
Jan> However, supporting transactions and journalling _is_ useful.
Jan> It would allow for a recovery into a consistent state.
Jan> MySQL is doing it, for the most part.
Jan> All that is missing, IMO, is a means of distinction
Jan> between committed and uncommitted transactions
Jan> in the update log.
Jan> I think the following twists that could do it:
<cut>
To be able to support transactions in the update log, we have to add a
behaveour that resembles a lot the one that you have described. The
only addition is that ROLLBACK will be possible...
Jan> --
Jan> Jan Dvorak
Jan> Tim Bunce wrote:
>>
>> Er, it doesn't. Your description of how commit works does not match
>> how Oracle, Ingres, Sybase etc work.
>>
>> I don't have time to write out a description, but a properly setup
>> database (e.g., log and tables on separate disks) then there will be no
>> data loss.
>>
>> In the case of power failure or kernel panic the recovery (rollback)
>> will be automatic and transparent. In the case of disk failure then
>> you'd need to restore your last backup and 'rollforward' the journal.
>> Either way, you'd end up with the database exactly as it was after the
>> last 'commit' was executed prior to the failure.
Note that the above is only 'almost' true. You can never guarantee the
above to 100 %, only to 99.99 % as there is always a small time
gap when the update log and database is not perfectly in sync. There
is also a small problem when the client don't get time to get the ok
from the server before it crashed. You can theoretically only make it
recover 'almost sure', never perfect.
