Metadata

Continuing with our Transaction Processing book reading , the second part of Chapter 7 covers degrees of isolation (and them co-existing), phantoms and predicate locks, how to implement predicate locking efficiently (via intent locks, and more exotic techniques), scheduling of locks, and dealing with deadlocks. I really liked these sections, as they contain many nice algorithmic ideas. The DB guys back then seemeed to have fun designing and then implementing these locking algebra/techniques. I miss the days where we could make up stuff/theory from first principles (because that is the "right" elegant thing to do)  and implement them with no fuss. Nowadays everything is too complicated, and we deal pieces in systems of systems where each things touches so many other that we are often zugzwanged out of innovation.  Below I borrow several paragraphs from the book to give a brief summary of the second part of Chapter 7.  Degrees of isolation Locking helps to provide the isolation

Continuing with our Transaction book reading , this week we look at the first part of the Isolation concepts. The book gets conceptual to provide the theory behind isolation of transactions. Finally we are getting some protocol action.  The first part of the chapter covers the following: Introduction to Isolation, The Dependency Model of Isolation (Three Bad Dependencies), Isolation: The Application Programmer’s View, and Isolation Theorems. A couple things immediately pop out. Chapter 7 equates Serializability (SER) with Isolation, whereas today snapshot isolation (SI) is the most popular isolation level, and we have a bunch of other weaker isolation levels .   Secondly, Chapter 7 equates two-phase-locking (2PL) with the isolation implementation techniques, whereas today MVCC and OCC are also popular implementation techniques. Although optimistic concurrency control (OCC) was established by 1980, the book did not consider OCC mechanisms at all.  This is normal, when we consider the

NVDIA CEO Jensen Huang recently made very contraversial remarks : "Over the course of the last 10 years, 15 years, almost everybody who sits on a stage like this would tell you that it is vital that your children learn computer science, and everybody should learn how to program. And in fact, it’s almost exactly the opposite. It is our job to create computing technology such that nobody has to program and that the programming language is human. Everybody in the world is now a programmer.  This is the miracle of artificial intelligence." I am not going to wise crack and say that this is power poisioning and this is what happens when your company valuation more than triples in a year and surpasses Amazon and Google. (Although I don't discount this effect completely.) Jensen is very smart and also has some great wisdom , so I think we should give this the benefit of doubt and try to respond in a thoughtful manner.  A response is warranted because this statement got a lot of p

This paper  declares the Jepsen testing of MongoDB for causal consistency a bit lacking in rigor, and goes on to test MongoDB against three variants of causal consistency (CC, CCv, and CM) under node failures, data movement, and network partitions. They also add TLA+ specifications of causal consistency and their checking algorithms, and verify them using the TLC model checker, and discuss how TLA+ specification can be related to Jepsen testing. This is a journal paper, so it is long. The writing could have been better. But it is apparent that a lot of effort went into the paper. One thing I didn't like in the paper was the wall-of-formalism around defining causal consistency in Section 2:Preliminaries. This was hard to follow. And I was upset about the use of operational definitions such as "bad patterns" for testing. Why couldn't they define this in a state-centric manner, as in the client-centric database isolation paper ? It turns out that Section 2 did not intr

"Transaction Processing Monitors" is chapter 5 as part of our transaction processing book reading journey.  This chapter had been the hardest to chapter to read and understand. It went into implementation concerns in contrast to the previous chapters which discussed design principles and concepts. It turns out 1980s were a very different time, and it is very hard to relate to the systems and infrastructure at that time. The people in our reading group also were lost, and found this chapter very hard to engage with.  1980s Ok, we are back at the year 1990 when this book is being written. This is when the internet and the web were still obscure.  Client-server processing is the modern thing then, and had just started to replace for time-sharing for databases and transaction processing. This chapter talks about transaction oriented processing. If I squint at it, I can see the concepts of SLAs and shared responsibility models between a cloud customer and provider in these descrip