Simultaneous INSERT/SELECT transactions or Read/Write operations handled in a database or file system

Question

Now, I am reading something about how a database or file system handles parallel executed transactions. And I know database and file system will do logging operations to ensure the failure atomicity of transactions. As my knowledge, write-ahead logging is a promising way.

The write-ahead logging will maintain another copy of the modified data. For the redo-logging, the to-be-updated data will first write into the logs and after that, the real updating will be done.

And what I am curious about is the following:

If at first, I do a large INSERT transaction I_TX into table A , and then during the I_TX, I do a SELECT transaction S_TX on the same table A, will I get the inserted data from the I_TX? And if I get it, is the data I get served from the logs or the real updated data ?

Thanks you.

Answer 1

The properties that you are referring to are the ACID properties of databases. This acronym stands for atomicity, consistency, isolation, and durability and has its own Wikipedia page . These are implemented more through locking than through logs.

These are very important properties of databases, and logging is an important component of their implementation. However, full implementation of ACID can incur a lot of overhead, so sometimes databases have more relaxed requirements, particularly on the visibility of data while being modified.

The answer to your question is that the select is resolved using data pages, not the log. The log is used for roll-back purposes. (There may be some cases where some databases do use the log.) The distinction is between data pages that are modified by the update transaction ("dirty pages") versus those that are not updated. Thee are several scenarios, such as:

• The select could read both modified and unmodified data pages.
• The select could wait and only read data from unmodified pages, whether before or after the transaction commits.
• The select could read unmodified pages as they are before the update ; and the update could (essentially) copy any pages being modified.
• The select could wait for the update to complete and then read the pages.

The first would be an inconsistent view of the data. The rest are consistent. The "correct" method is some way for the select to see consistent views of the data. Some databases, to allow reading of pages that are "dirty", meaning they are part of a transaction but not committed. This is not strictly ACID-compliant, but it is faster.

Also, different databases have different support for various locking mechanisms and for how much they can be overridden. Databases even differ on whether the update "auto-commits" or must wait for an explicit commit.