List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:January 18 2000 11:22pm
Subject:Re: Understanding Transactions...
View as plain text  
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.
Thread
Understanding Transactions...rjb17 Jan
  • Re: Understanding Transactions...sinisa17 Jan
  • Re: Understanding Transactions...Doug Robinson17 Jan
    • Re: Understanding Transactions...sinisa17 Jan
    • Re: Understanding Transactions...Gregor Welters22 Feb
  • Re: Understanding Transactions...Sasha Pachev17 Jan
    • Re: Understanding Transactions...Tim Bunce17 Jan
      • Re: Understanding Transactions...sinisa18 Jan
        • Re: Understanding Transactions...Tim Bunce18 Jan
          • Re: Understanding Transactions...sinisa18 Jan
            • Re: Understanding Transactions...Tim Bunce18 Jan
              • Re: Understanding Transactions...sinisa18 Jan
                • Re: Understanding Transactions...Tim Bunce18 Jan
                  • Re: Understanding Transactions...sinisa19 Jan
                    • Re: Understanding Transactions...Tim Bunce20 Jan
          • Re: Understanding Transactions...Michael Widenius26 Jan
      • Re: Understanding Transactions...Christopher E. Brown18 Jan
        • Re: Understanding Transactions...James Rogers18 Jan
          • Re: Understanding Transactions...sinisa19 Jan
      • Re: Understanding Transactions...Michael Widenius26 Jan
        • Re: Understanding Transactions...Tim Bunce27 Jan
  • Re: Understanding Transactions...rjb17 Jan
  • Re: Understanding Transactions...Sasha Pachev17 Jan
  • Re: Understanding Transactions...Sven E. van 't Veer18 Jan
    • Re: Understanding Transactions...sinisa18 Jan
      • Re[2]: Understanding Transactions...Sven E. van 't Veer18 Jan
  • Re: Understanding Transactions...Jan Dvorak18 Jan
    • Re: Understanding Transactions...Michael Widenius18 Jan
      • Re: Understanding Transactions...Tim Bunce19 Jan
        • Re: Understanding Transactions...Patrick Greenwell19 Jan
          • Re: Understanding Transactions...sasha19 Jan
            • Re: Understanding Transactions...Patrick Greenwell19 Jan
              • Re: Understanding Transactions...Michael Widenius19 Jan
                • MySQL specific filesystemPatrick Greenwell19 Jan
          • Re: Understanding Transactions...Michael Widenius19 Jan
        • Re: Understanding Transactions...Michael Widenius19 Jan
          • Re: Understanding Transactions...Tim Bunce19 Jan
            • Re: Understanding Transactions...Michael Widenius19 Jan
              • Re: Understanding Transactions...Tim Bunce20 Jan
                • Re: Understanding Transactions...sinisa20 Jan