DBMS Transaction and Serializable

Question

We know:

A schedule in which transactions are aligned in such a way that one transaction is executed first. When the first transaction completes its cycle then next transaction is executed. Transactions are ordered one after other. This type of schedule is called serial schedule as transactions are executed in a serial manner.

and

This execution does no harm if two transactions are mutually independent and working on different segment of data but in case these two transactions are working on same data, results may vary.

so what is the benefit of finding that two transaction is Serialize Schedule? if the result is vary, what is the benefit ?

Answer 1

When transactions access the same variables but are executed serially (ie not executed simultaneously) there is a sense in which "results may vary" from when there is only one transaction ever executing (possibly repeatedly). With serial transactions we don't know what order the (non-overlapping) transactions are executed in. All we know at the start of the execution of a repeating transaction is that other transactions may have changed variables since the end of the last execution of the repeating transaction. (Although we generally know something about how they have been left.)

There is nothing wrong with such "varying results" because they just reflect that the transactions were requested at varying times.

When transactions access the same variables and are executed simultaneously (ie not serially) then then for each transaction "results may vary" (in another sense) from how we normally understand the code. That normal understanding relies on only one transaction executing at a time. Eg normally if code reads a variable twice without writing to it then we expect to get the same value. But that's not guaranteed if another transaction writes to it in between reads. Eg normally if code reads a variable then we expect to get the value that the variable actually had. But that's not guaranteed if we get some of its bytes and then another transaction writes to it and then we get the rest of the bytes from that new value.

But if transactions are serializable then they can be executed non-serially (with overlap) but with the same result as if they were executed serially (with no overlap). Then code means what it normally means when there is only one transaction executing.

So we have to make sure that the system acts as if transactions are serial or else we have no idea what our program does.

A serializable schedule is an interleaving of operations from multiple transactions that gives the same result as some serial(ized) schedule. The benefit of executing a serializable schedule that is different from just doing all of one transaction's operations after another's is improved throughput from doing multiple operations from multiple transactions at the same time.

PS

Your quotes appear on a web page that is a mess. It doesn't even define "serializable schedule". The text between your quotations is

In a multi-transaction environment, serial schedules are considered as benchmark. The execution sequence of instruction in a transaction cannot be changed but two transactions can have their instruction executed in random fashion.

But the second sentence should start But in a non-serial schedule.... Because in a serial schedule "Transactions are ordered one after other." So the "results may vary" in the quotation is in a non-serial schedule.

But you did not respond to my comment:

Does "This execution" refer to a serial execution of transactions or to a non-serial execution of transactions? (What came before your second quote?)