Re: "Transactions are bad, real bad" - discuss

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:5NXra.8$i92.264_at_news.oracle.com...
>
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:b8ljgd$383i$3_at_gazette.almaden.ibm.com...
> > With transactions, this rule is compromised. A user could simply open a
> > transaction before the end of the 1 hour deadline, make a bid at then only
> > decide to commit (or rollback) the bid at his leisure after the end of the
> > deadline.
>
> Isn't this problem trivally solved by "flashback" query that auction
> organizer can run?
>
> select max(amount) from bids AS OF "30-APR-2002 12:00"
>
> Any transaction not committed before "30-APR-2002 12:00" would have no
> effect onto the query resultset.

Don't you think that this just highlights why transactions are troublesome?

AS OF "30-APR-2002 12:00"
    the max bid in the auction closing as 12:00 was $10

AS OF "30-APR-2002 12:15"
    the max bid in the auction closing as 12:00 was $12

Don't we want the timeline that the 'auction closing time' is part of to be the same as the timeline that 'row insertion timestamp' is part of and both be the same as the AS OF timeline?

In the above we have two time lines.

    The AS OF timeline that is corrent and consistent - it only moves forward and at any given time there is one state of the database.

    The CURRENT TIMESTAMP timeline that can lag the AS OF timeline. This allows changes to appear 'in the past' - it make time travel possiable. Not, IMO a good model of reality.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Thu May 01 2003 - 14:42:56 CEST