What are some common locking scenarios and patterns in different database systems?

I would rewrite the first sentence as follows: "Shared locks allow multiple transactions to read the same data simultaneously, but prevents modification until all shared locks have been released. Shared locks are also called read locks, and are used for maintaining read integrity." I would rewrite the second sentence as follows: "Exclusive locks allow only one transaction access to read or modify data at a given time. No other transactions can read or modify the data until the current transaction releases its Exclusive lock. Exclusive locks are also known as write locks. No changes for the third sentence.

Both Optimistic Locking and Pessimistic Locking happen at the application level to avoid the race condition. Optimistic locking should be considered, when we expect low to moderate contention for the shared resource. If we apply this lock for the high contention resource, we may lose CPU time by redoing the operations. Pessimistic locking should be considered for the high contention and critical transactions. This makes the particular transaction to execute in serial manner and make the other threads to wait, since integrity of the transaction is needed.

I would rewrite the first sentence as follows: "Row-level locking allows multiple transactions to read or modify distinct rows in the same table simultaneously, by locking each rows when accessed." I would rewrite the third sentence as follows: "Table-level locking locks the entire table once it is accessed by a transaction, preventing all other transaction access until the current transaction completes."

These algorithms use compare-and-swap (CAS) which is a machine level atomic operation. It involves 3 steps wrapped in to 1 performed by the thread trying to update the resource - read value, compare with last know value(which was read is prev separate step), update if matches or fail if not matches(which means some other thread updated it in between) and retry update. Example: 1. Read A -> 5 2. CAS(5, 4) So, in step 2 CAS instead of simple update ensures that if value was changed after step 1 by someone else, that is taken into account, without the need to lock.

una forma es escribir documentos implementando una sucesión de códigos hash de cifrado y así garantizar que los datos son consecutivos. seria algo como la arquitectura de bitcoin que se utilizaría en un campo de control en el documento de la colección que requiere mantener la integridad y la consistencia de sus datos.

IMS has an interesting feature for when you think you may know better than the DBMS when to lock (smiley face). It's called the Q command code. It allows you to purposefully lock segments (like records) if you want to make sure there are no updates until you complete some UOW (Unit of Work).