List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:January 19 2000 2:26am
Subject:Re: Understanding Transactions...
View as plain text  
>>>>> "Tim" == Tim Bunce <Tim.Bunce@stripped> writes:

Tim> On Wed, Jan 19, 2000 at 01:22:39AM +0200, Michael Widenius wrote:
>> 
>> 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.

Tim> Interesting.

Tim> Given the responses in this thread I guess most people will be
Tim> disapointed that that work will delay other "more important" work ;-)

>> 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...

Tim> How will you deal with transaction isolation?

You will have the commands TRANSACTION START, COMMIT and ROLLBACK.
This should take care of the above problem.

Tim> Yes there is a time when the update log and database is not perfectly
Tim> in sync.  In fact that can be quite a long time because delayed writing
Tim> of the data tables is a valid optimisation that I know Ingres uses
Tim> and I think Oracle and others do as well. (I did all this RDBMS
Tim> optimization theory back when I was using Ingres 6.4.)

This will help somewhat;  But you still have a small time slice
between the write and the flush when things can go wrong and you can't
know if you got the last transaction done or not.

Tim> That's an important optimisation for transactional RDBMS.

Tim> While I'm very happy that MySQL is moving in the direction of
Tim> supporting transactions I'd caution that it's not something that'll be
Tim> implemented well in a week or 10 weeks. The complications are manifold.
Tim> I'm sure you know this already. I hope you can adopt a plan that lets
Tim> you move forward in small careful steps alongside other developments.

Just wait and see;  This will be ready much sooner than you expect...

>> 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.

Tim> I don't see the big problem here. The only issue is that the client
Tim> may get a "false negative" from the "commit" because there's a tiny
Tim> chance it will return with a "connection dropped" error even though
Tim> the commit was successful. The recovery when the server is restarted
Tim> should be fine, in the sense that it will recover to the last commit.

But the client doesn't know if the command was successful or even if
he got an automatic rollback. He doesn't even have any way of checking
this.  This can be as bad as a lost transaction in the worst case.

(Note that we are of course discussing improbable situation, but if we
are talking about 100 % security, this issue must also be solved)

Regards,
Monty
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