Re: Transactions: good or bad?

From: Nigel Day <nigelday_at_fast24.co.uk>
Date: Tue, 6 May 2003 12:05:25 +0100
Message-ID: <b985990ikl_at_enews2.newsguy.com>


A transaction is what the DBMS lets you do as a unitary operation: its a group of changes to be performed as a unit, such that if anything goes wrong the whole set is rolled back. So transactions per se don't give problems with the 'arrow of time', it's where they are combined with the use of locking. Thus, if you have a database recording the current values of analogue and digital sensors in a factory / power station / whatever, locking a record whilst you adjust the alarm limit values for a sensor could be disastrous, as it would block updates to the current value attribute; safety software that relies on the timeliness of readings might not see a problem until too late. In such circumstances, one avoids the use of locking - thus maintaining the dynamic accuracy of the database (as well as the internal consistency granted by transactions) - and rely on techniques such as optimistic concurrency control and/or active database code to avoid the need for locking.

Nigel Day

"Todd Bandrowsky" <anakin_at_unitedsoftworks.com> wrote in message news:af3d9224.0305050819.2b2ffe4c_at_posting.google.com...
> 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:
>
> a) Does the history have to be that exact, and,
>
> b) 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 Tue May 06 2003 - 13:05:25 CEST

Original text of this message