Six DBMS Lectures and the Confusion Between Three Schedules

Saturday was a productive day for my GATE CSE 2027 preparation. I completed six lectures from DBMS Chapter 2, Transaction and Concurrency Control, and spent the day learning concepts that are important for understanding database transactions and solving GATE questions.

This chapter has quite a few technical terms that sound similar but mean different things. Some concepts made sense as I studied them, while others required a little more effort to understand and recall correctly.

Let's go through what I covered.

Six Lectures of DBMS on Saturday

My target for the weekend was to make substantial progress in DBMS. I wanted to complete Chapter 2, Transaction and Concurrency Control, and work towards completing Chapter 3, ER Model, by Sunday.

On Saturday, I completed six lectures from the transaction chapter.

I studied transactions, scheduling, serializability, and recoverability. These concepts are connected, so understanding the basics is important before moving towards more complicated problems.

I had already been learning about ACID properties and transaction states. This time, my attention moved towards how transactions execute together and how we determine whether a schedule is correct.

Understanding Serial and Non-Serial Schedules

I started learning about transaction schedules and the difference between serial and non-serial execution.

A serial schedule executes one transaction completely before starting another. A non-serial schedule allows operations from different transactions to be interleaved.

I also learned about the number of possible schedules.

For example, if there are two transactions containing m and n operations, respectively, and the internal order of operations in each transaction must remain unchanged, the total number of possible interleavings is:

(m + n)! / (m! × n!)

If there are k transactions and we are counting only the possible serial orders, the formula is:

k!

These formulas help distinguish between counting all valid interleavings and counting only serial schedules.

Conflict Serializability and View Serializability

Next came serializability, one of the important parts of transaction scheduling.

I learned about two types:

• Conflict serializability
• View serializability

The relationship between them is important: every conflict-serializable schedule is view-serializable, but not every view-serializable schedule is conflict-serializable.

I also studied conflicting operations. Two operations conflict when they belong to different transactions, access the same data item, and at least one of them is a write.

The three possible types are:

• Read-Write (RW)
• Write-Read (WR)
• Write-Write (WW)

Understanding these conflicts is essential when checking whether a schedule is conflict-serializable.

I also studied conflict equivalence, which involves swapping adjacent non-conflicting operations to transform one schedule into another without changing the relative order of conflicting operations.

After that, I moved on to view serializability and the conditions for view equivalence. These involve preserving initial reads, read-from relationships, and final writes.

There were several definitions to remember, so I had to pay attention to the differences rather than simply memorizing the terminology.

The Part That Confused Me: Recoverable, Cascadeless, and Strict Schedules

This was the part where I realised that recognising a definition during a lecture is not the same as being able to recall it accurately.

I studied three types of schedules:

1. Recoverable schedules
2. Cascadeless schedules
3. Strict schedules

Initially, I could remember the general idea, but I struggled to explain the exact difference between cascadeless and strict schedules.

After discussing the concepts in simpler language, the distinction became much clearer.

Recoverable schedule: If transaction T2 reads a value written by T1, T2 must not commit before T1 commits. T2 may read the uncommitted value, but its commit must wait for T1's commit.

Cascadeless schedule: T2 cannot read a value written by T1 until T1 has committed. This prevents dirty reads and avoids cascading rollbacks caused by reading uncommitted data.

Strict schedule: If T1 has written a data item, another transaction cannot read or write that item until T1 commits or aborts.

The easiest way I found to remember the difference is:

• Recoverable: control the order of commits.
• Cascadeless: prevent reading uncommitted data.
• Strict: prevent both reading and writing data written by an uncommitted transaction.

This explanation helped me understand why strict schedules impose a stronger restriction than cascadeless schedules.

I was happy that the distinction finally made sense. These are exactly the kinds of concepts where a small difference in wording can change the answer to a GATE question.

A Note on Concurrency Problems

While studying conflicting operations, I also tried to connect RW, WR, and WW conflicts with concurrency anomalies, including dirty reads and lost updates. I came across phantom reads as well.

I still need to make the relationship between these operation conflicts and specific anomalies more precise. They are related concepts, but the names of the conflicting operation pairs should not be treated as interchangeable with the names of the anomalies themselves.

That is something I need to remember when revising this chapter.

What I Learned Today

The biggest lesson from Saturday was that technical definitions need to be understood well enough to explain them in my own words.

I completed six lectures, but I still had difficulty recalling some definitions correctly. Rather than pretending I understood everything, I paused and worked through the confusing part.

That helped me understand the three schedule properties much better.

For GATE CSE preparation, this matters because a question may look familiar while testing a small distinction that I have forgotten. Merely recognising a term is not enough; I need to know exactly what it means and how to apply it.

Tomorrow: More DBMS

My next target is to continue with DBMS on Sunday.

I want to make progress towards completing both Chapter 2, Transaction and Concurrency Control, and Chapter 3, ER Model, over the weekend.

My overall syllabus deadline remains 30 October. With that deadline approaching, I need to balance moving through the remaining syllabus with understanding the concepts properly.

Saturday was a good step forward. I completed six lectures and cleared up a confusing concept, although I still need more practice to make these definitions easier to recall.

One day at a time, one chapter at a time.