ACID transactions

Actions with data that have the properties of atomicity, consistency, isolation and Durability is the ACID definition of a transaction.

D – Durability is the same model I was talking about: if the data has already been written to disk, then we believe that it is there, recorded securely and will not go anywhere. In fact, this is not the case, for example, the data needs to be backed up, but for our model this is not important.

Sadly, these properties can only be provided with locks. There are 3 main approaches to transaction shedding:

Pessimistic shedulers;
Optimistic shedulers;
Hybrid Schedulers and Ordering TimeStamp of an ongoing transaction.

Scheduler is a component that ensures that a transaction is serialized and executed correctly.

Everyone knows about the ordering of TimeStamp: we look at the time of one transaction, the time of another transaction, who got up first, that and the slippers. In fact, for most serious systems, this approach has a lot of problems, because, to begin with, the time on the server can go backwards, it can jump or go wrong – and we will arrive.

There are various methods to improve this, but as the only method for synchronizing transactions, it does not work. There is also a vector clock, Lamport’s clock – you must have heard such terms – but they also have their limitations.

Optimistic approaches mean that we will not have conflicts like what I described with a bank account. But in real life they do not work very successfully, although there are implementations that help carry out some operations using optimistic options.

As people working with databases, we are actually always pessimists. We expect programmers to write bad code, the supplier will supply bad hardware, Mary Ivanna will unplug the server when she is cleaning the floor – what could not be!

Therefore, we love pessimistic transaction scheduling, namely with the help of locks. This is the only guaranteed way to ensure the integrity of your databases. There are corresponding theorems that can be proved and demonstrated.

We need efficient algorithms for taking and unlocking locks, because if we just block everything we need, most likely we will end up with a very dumb version, when we perform all operations strictly sequentially. As we already know, this is not efficient in terms of utilization of parallelism, modern CPUs, number of servers, etc.