Optimistic Offline Lock ,Pessimistic Offline Lock ,Coarse Grained Lock ,Implicit Lock

Optimistic Offline Lock (Optimistic Lock)
Pessimistic Offline Lock (Pessimistic Lock)
Coarse Grained Lock (Rough Lock)
Implicit Lock (Hidden lock)

Optimistic Offline Lock (Optimistic Lock)
Optimistic Offline Lock Design Pattern

Optimistic Offline Lock Design Pattern

Optimistic Offline Lock Description
Prevents conflicts between competing business transactions, identifying them and rolling back the transaction.

Often a business transaction involves performing multiple system transactions. Going beyond a single system transaction, we cannot rely only on the database management system to make sure that the business transaction leaves the data in a consistent state. Data integrity is compromised every time two business transactions start working on the same data. It may also happen that one process reads the data while the other is updating.

The Optimistic Offline Lock pattern solves this problem by checking the completion of one transaction and the absence of conflicts with another. A successful pre-commit check, in a sense, receives a blocking signal that you can continue to work with changes in the data. Since validation occurs during the completion of each system transaction, business transactions will also be consistent.

While Pessimistic Offline Lock implies that the chance of a session for a conflict is high and therefore restricts systemic competition, Optimistic Offline Lock implies that the chances of a conflict are not great. This assumption is not very suitable for the simultaneous work of several users on the same data.

Pessimistic Offline Lock (Pessimistic Lock)
Pessimistic Offline Lock Design Pattern

Pessimistic Offline Lock Design Pattern

Pessimistic Offline Lock Description
Prevents conflicts between competing business transactions, allowing access to one data only one business transaction at a time.

Since local competition involves working with business transaction data that contains multiple requests, the simplest approach would be to keep the transaction open throughout the business transaction. But, unfortunately, this approach does not always work well, because transaction management systems are not designed to work with long-term transactions. So you have to do several system transactions, and monitor the rest of the competition yourself.

The first approach to try in this case is Optimistic Offline Lock. However, this pattern has its drawbacks. For example, if several people try to access one data in one business transaction, one of them can easily commit, but the rest will get a conflict and will not be able to continue working. Due to the fact that conflicts are determined only at the end of a business transaction (and not prevented), the victims will do all the actions of the transaction and at the last moment find out that all their work is in disarray. If this happens, systems with long transactions will soon become unpopular.

Pessimistic Offline Lock prevents conflicts by eliminating them altogether. This pattern causes a business transaction to impose a lock on that part of the data it is working with, so that in order to start working with data, another user first waits for the data to become free.

example

The shared lock method is intended for use in Laravel locking. The method prevents selected rows from being modified until the completion of your transaction:

DB :: table ('users') -> where ('votes', '>', 100) -> sharedLock () -> get ();
Another option is to use the lockForUpdate method. The "for update" lock protects the selected lines from being modified and from the installation of the "shared lock" lock:

DB :: table ('users') -> where ('votes', '>', 100) -> lockForUpdate () -> get ();

Coarse Grained Lock (Rough Lock)
Coarse Grained Lock Design Pattern

Coarse Grained Lock Design Pattern

Description Coarse Grained Lock
Locks a set of related objects with one lock.

Objects can often be edited in a group. For example, there is a client and a set of his addresses. In this case, you can block them all, if you need to contact one of them. Locking them separately will lead to a lot of problems. First of all, anyone who tries to work with such data will be forced to create code to search for all records in order to block them later. This is quite simple in the example with client and addresses, but what if the group is more complex or there are more groups. Where to put part of the program logic, which is responsible for the merging of locks. If a blocking strategy includes a rule according to which an object must be loaded before blocking, as in Optimistic Offline Lock, for example, blocking a large array of objects will cause a performance failure. And in the case of Pessimistic Offline Lock, a large lock will cause problems with management and increase competition for blocking.