Transaction Time in transactional DBMS?

From: <Christian.D.Schnell_at_t-online.de>
Date: Tue, 16 Oct 2001 11:07:22 +0200
Message-ID: <12unst8gb8hsvaos6o2gbio967746b8ed6_at_4ax.com>

Hi. I recently got into the very promising field of temporal databases, and I have some questions. Please excuse any misunderstandings, correct me wherever I'm wrong.

The Transaction Time is defined as the time when a database fact is 'current in the database and may be retrieved'. Sounds nice, but doesn't that bite with transactions?

With transactions, the Transaction Time interval of a database fact has two different beginnings, one for the writer (when he writes the fact) and one for all other readers (when the writer commits his transaction). Which one is it the right one?

I think, it is not necessarily the instant of commit. Think of a long-running transaction, that updates a single record multiple times during that. These different states of the record do not have the same transaction time (beginning)!

That makes me think, that the only valid representation of transaction time instant in a transactional database management system is a tuple of (Transaction Time, Valid Time). Is this correct?

Another question: What instant to choose for a Transaction Time value? In my understanding, it should be the time of commit, because that is the beginning of the time when the fact was available for /every/ reader of the database. BUT: What if the transaction time needs to be known within the transaction? Are temporal Databases and transactional Databases incompatible, in this respect?

A final question: Does the transaction time have it's name because it is required to be constant in each transaction? Is that actually required? The glossary isn't really clear about that, I think.

Thanks and greetings,
Christian Schnell. Received on Tue Oct 16 2001 - 11:07:22 CEST