Re: Transactions: good or bad?

I'm going to make the argument that the statement "transactions are not compatible with the arrow of time" misses the point of what transactions are for.

In a multiuser system, serialized transactions are the only way to accurately ensure that multiple users produce a consistent and accurate history of events.

The big point that people debate, really, about transactions, are:

1. Does the history have to be that exact, and,
2. is the price to pay for that accurate history worth it?

Fully serialized isolation levels makes a lot of demands. Therefor, most databases out there are not actually using a full blown serialization to run. For example, SQL Server uses READ COMMITTED as a default and even Oracle / PostGres vaunted MVCC have the achilles heel of having to rollback downstream transactions.

I for one think that in the future we will see more domain specific database servers that make use of business knowledge in the domain they serve to schedule operations more effectively. Instead of writing to a general purpose SQL like thing, you will write to a litigation support server, a commodity server, a freight management server, etc. Underneath, they will all have to follow the same physical theory that governs an RDBMS, but, they will be able to take advantage of edge cases better to provide maximum multiuser concurrence while satisfying business level demands for accurate data.

>
> But recently I read that "transactions ... are not compatible
> with the 'arrow of time'. They let you freeze time and that
> is not a good model of reality."
>
> Any comments?
>
>
> Marshall
Received on Mon May 05 2003 - 18:19:13 CEST