> > Yes, but have you ever seen a database running under some form of
> > comitment control actually perform a rollback?
>
> Yes, but computational cost is not an issue. Ideally we are not needing
> to rollback unless there's been a commit of corrupted data, which should
> be a rare enough case in itself. It's a failsafe so that we don't need to
> abandon world state if we have a fault.
>
Well, that's not always exactly true. I've been working with large
databases (500 gigs or so, with two or three mirrored servers and a
developement server) - every so often, it's advantageous to perform a set
of queries in a tight loop and then rollback if, at the end, we detect a
reason to do so. This is better than peforming incremental testing; most
of which involves heavy statistical math and is inefficient, especially if
we're looking at historical summaries of data which potentially change
which each new entry.
Granted, rollbacks are only really used if the programmer or DBA
messes up somewhere, but humans seem to make enough of these types of
mistakes. If they didn't, we wouldn't have debuggers either :)
As for rollbacks in the mud environment, I can see rolling back to
the transaction before that which was associated with a crash. Asuming
full world persistance, you can 'just keep going'.
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT