Lightning-fast message processing with the power of concurrency control and optimistic locking

SleekFlow’s lightning-fast message processing: the power of concurrency control and optimistic locking

Technology has framed our dynamic digital environment today, and businesses need to respond to customer inquiries and engagement as quickly as possible to keep up with the pace. SleekFlow, an omnichannel messaging customer engagement platform, is at the forefront of this rapid communication revolution. By employing advanced concurrency control and optimistic locking, messages can be processed at incredible speeds, so that the customers receive relevant responses timely.

SleekFlow Google Play mobile app download

Concurrency control: the key to efficient message handling

Concurrency control is a crucial component of any high-performance messaging system. It manages simultaneous access to shared resources, such as message queues or databases, ensuring that all operations are executed seamlessly without causing conflicts or inconsistencies. SleekFlow’s innovative approach to concurrency control allows it to handle multiple customer interactions across various channels simultaneously, without sacrificing speed or reliability.

SleekFlow channels

What is optimistic locking?

Optimistic locking is a concurrency control mechanism that assumes infrequent resource conflicts between transactions. Instead of locking resources upfront, it allows multiple transactions to operate simultaneously, with the assumption that conflicts will be minimal.

Optimistic locking: the path to uninterrupted message flow

To further enhance platform performance, optimistic locking has been integrated into various systems in SleekFlow.

When a conflict does occur, for example, when two agents attempt to update the user profile of the same customer at the same time, optimistic locking detects the collision and rolls back one of the transactions. This ensures that the system maintains consistency and prevents data corruption. The rolled-back transaction is then retried, allowing the agent’s response to be sent as soon as possible.

Optimistic locking provides several benefits for SleekFlow’s systems:

1. Increased performance

By allowing simultaneous access to shared resources, optimistic locking boosts the system’s overall performance and responsiveness.

2. Improved scalability

As the number of concurrent transactions grows, SleekFlow’s optimistic locking mechanism can easily handle the increased load without compromising speed or reliability.

3. Enhanced user experience

Agents can work on customer messages without worrying about conflicts or delays, leading to a smoother and more efficient customer engagement process.

What is concurrency control?

A concurrent situation is the multiple usages of a shared data resource. When there is a possibility of concurrency in the program, it is necessary to ensure the accuracy of the data under concurrent conditions, to guarantee that a current user, who operates together with other users, obtains the same results as to when he operates alone. This is called concurrency control. The purpose of concurrency control is to ensure that the work of one user does not unreasonably affect the work of another user.

3 concurrent situations in databases

  1. Read-Write

  2. Write-Read

  3. Write-Write

1. Read-Write

After Transaction 1 (T1) reads the data, Transaction 2 (T2) performs an update on the data, which causes the inability for T1 to read the original data again. There can be two situations:

T2 modifies the data. When T1 reads the data again, the retrieved data is different from the previous read. The situation is known as a Non-repeatable Read.

T1

T2

Read(A) = 10

Read(A) = 10

A = A + 5 = 15

Write(A) = 15

Read(A) = 15

T2 deletes the data. When T1 reads the data again, some data disappears or some new data are retrieved. This situation is known as Phantom Read.

T1

T2

Read(A) = 10

Read(A) = 10

A = A + 5 = 15

Write(A) = 15

Read(A) = 15

2. Write-Read

Transaction 1 (T1) modifies some data and Transaction 2 (T2) reads the uncommitted data. However, T1 is cancelled due to some reasons and the data is rollbacked to the original value. Therefore, T2 reads the incorrect data. This situation is known as Dirty Read.

T1

T2

Read(A) = 10

A = A * 2 = 20

Write(A) = 20

Read(A) = 20

Rollback

A = 10

3. Write-Write

Transaction 1 (T1) and Transaction 2 (T2) read the same data and write at the same time. T2 corrupts T1 and causes T1’s modification to be lost.

T1

T2

Read(A) = 10

Read(A) = 10

A = 1 - 1 = 9

Write(A) = 9

A = A - 2 = 8

Write(A) = 8

Locks in concurrency control: optimistic locking vs. pessimistic locking

Locks of concurrency control for speed

Both pessimistic lock and optimistic lock are the principle or philosophy of handling concurrency problems. A pessimistic lock is like a pessimistic person in life who always believes in things leading to bad directions. An optimistic lock is like an optimistic person in life who always believes in positive things leading to a good direction.

How does a pessimistic lock (Pessimistic Concurrency Control — PCC) work

The pessimistic lock, also referred to as the pessimistic concurrency control, prevents simultaneous updates to data. When modifying a piece of data in the database, in order to avoid the data being modified by others at the same time, the best way is to directly lock the data to prevent concurrency.

A pessimistic lock has strong exclusive characteristics. It refers to a conservative attitude towards data being modified by the outside world (including other current transactions in the system, as well as transactions from external systems). Therefore, during the entire data processing, the data is kept in a locked state.

  • Pros: It is suitable to be used in a concurrent environment with less reading and more writing. Although it cannot maintain very high performance, it can achieve data security under the premise that optimistic locking cannot provide better performance.

  • Cons: Locking will increase the system overhead. Although it can ensure the security of data, the throughput of data processing is low, and it is not suitable for use in occasions with more reads and fewer writes.

Implementation of pessimistic locks

Implementation of Pessimistic Locks for concurrency problems

Categories of pessimistic locks

  • Exclusive Lock (X-Lock)
    If transaction T adds X-lock to data object A, only T is allowed to read and modify A, and no other transaction can add any lock to A until T releases the lock on A.

  • Shared Lock (S-Lock)
    If transaction T adds S-lock to data object A, transaction T can read A but cannot modify A, other transactions can only add S lock to A, but not X lock until T releases the lock on A.

Pessimistic lock compatibilities

X-Lock

S-Lock

X-Lock

X

X

/

S-Lock

X

/

/

/

/

/

How does a optimistic lock (Optimistic Concurrency Control — OCC) work

The optimistic lock, also referred to as the optimistic concurrency control does not use data locking in databases. Optimistic locking believes that no other thread will perform operations when one thread operates specific data, so it will not lock the data at the beginning, but only verify whether the data has been modified by other threads when submitting the modification.

  • Pros: In a concurrent scenario with more reads and fewer writes, the overhead of database locking can be avoided and the response performance of the database service can be improved. In fact, ORM tools have implementations with optimistic locking, so these methods do not necessarily require us to implement artificially.

  • Cons: In the concurrent scenario of reading less and writing more, in other words, in the case of fierce competition for write operations, CAS will be retried many times, and the conflict frequency is too high, resulting in higher overhead than pessimistic locks.

Implementation of optimistic locking

Implementation of Optimistic Locking for concurrency problems

Is optimistic lock really a “Lock”? — the philosophy of Compare And Swap (CAS)

The optimistic lock is not implemented by the locking mechanism of the database management system. The data source is not locked when it is accessed by a transaction.

Compare and Swap, or CAS, is a mechanism used to solve performance loss caused by locks in the case of multi-threaded parallelism. The CAS operation contains three operands — memory location (V), expected original value (A), and new value (B). If the value of the memory location (V) matches the expected original value (A), the processor automatically updates the location value to the new value (B). Otherwise, the processor does nothing.

What about the ABA Problem?

The ABA problem occurs when multiple threads access shared data interleave. Assume there is the data value A, one thread changes it to B and changes it back to A. The CAS does know whether the value is changed or not.

The ABA problem of Optimistic Locking

Version/Timestamp-based CAS

One solution to avoid the ABA problem is to add an auto-incremental column.

Each time the optimistic lock performs a data modification operation, it will bring a version number. Once the current version number is consistent with the version number of the data read for the first time in this transaction, the modification operation can be performed and the version number can be executed “+1” for the action; otherwise, the execution fails. Because the version number is incremented with each operation, there are no ABA issues. We can also use a timestamp to record data modification because the timestamp is incremental.

Pessimistic lock vs. optimistic lock: which one should I choose?

In the choice of optimistic lock and pessimistic lock, mainly look at the differences and the applicable scenarios for your platform.

1. Response efficiency

If the database access service needs a very high response speed, especially in the scenario of more reading and less writing, then we can use optimistic locking to reduce the overhead of database locks and increase concurrency.

2. Conflict frequency

If the conflict frequency is very high, then we can use a pessimistic lock to ensure the write success rate. After all, if the conflict frequency is high, an optimistic lock will require multiple retries to succeed, and the cost may greatly increase.

3. Retry cost

If the retry cost is high, for example, the code execution of the retry process is very time-consuming, then it is not recommended to use optimistic locking at this time, it is better to directly use pessimistic lock to ensure the success rate.

Conclusion

By harnessing the power of concurrency control and optimistic locking, SleekFlow has created a lightning-fast system that can keep up with the demands of today’s digital customers. With its ability to process messages quickly and efficiently, SleekFlow ensures that businesses can provide top-notch customer engagement across all channels, keeping clients satisfied and coming back for more.

Did you know that you can do custom integrations with SleekFlow?

Share Article

Recommended for you

Automate your growth with

Get started for free and supercharge your customer engagement.