Do log files demand serialization?

Oracle, SQL Server, etc, all use transaction logs to preserve isolation, and to offer rollback and commit.

While I understand how a database can achieve good isolation using logging, what I do not understand is how that log can be consistent.

Assume two kinds of logging scenarios:

1. the log is written with the "prior" contents of the database table. The active writer directly updates the table. On rollback, the contents of the log are put back into the table. On commit, the log entry is marked as such. When users want to do a read on an area of a table where another transaction may be writing to it, the system reads from the log for those users.
2. the log is written with the "new" contents of the database table. The active writer updates the log. On rollback, nothing happens. On commit, the contents of the log are copied into the table. When another reader wants to read where the writer may be writing, the contents of the table are returned.

In both cases, a user can read the "old stuff" while another user may be writing a newer version. In both cases, commit and rollback are supported. However, in both cases, it seems that it is necessary to serialize access to the transaction log itself.

In fact, I'm not even sure how one would have a commit and rollback scheme that does not demand serialized access to a transaction log. Is this true in general? I might, if I have 50 users doing inserts, updates, etc, wouldn't Oracle, SQL Server, etc, always have to serialize the log? If so, doesn't the serialization to the log ultimately limit its scalability? Doesn't ACID ultimately mean serialization at some point, or I am just completely wrong?

Please let me know.

Thanks! Received on Tue Feb 12 2002 - 12:30:26 CST