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