# concurrency-control

Published articles for concurrency-control.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## How to Deal With Errors and Failures in LLM-Powered Applications

DevFeed: [How to Deal With Errors and Failures in LLM-Powered Applications](<https://devfeed.tech/articles/how-to-deal-with-errors-and-failures-in-llm-powered-applications-17991.md>)

Original publisher: [Read original article](<https://blog.bytebytego.com/p/how-to-deal-with-errors-and-failures>)

Author: ByteByteGo

Published: 2026-09-07T15:31:35Z

Content type: tutorial

Language: en

Sources: [ByteByteGo](<https://devfeed.tech/sources/bytebytego.md>)

Topics: [Large Language Model](<https://devfeed.tech/topics/llm.md>), [App](<https://devfeed.tech/topics/app.md>), [Language models](<https://devfeed.tech/topics/language-models.md>)

Tags: [applications](<https://devfeed.tech/tags/applications.md>), [concurrency-control](<https://devfeed.tech/tags/concurrency-control.md>), [errors](<https://devfeed.tech/tags/errors.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [llm](<https://devfeed.tech/tags/llm.md>), [rate-limiting](<https://devfeed.tech/tags/rate-limiting.md>), [resiliency](<https://devfeed.tech/tags/resiliency.md>), [retry](<https://devfeed.tech/tags/retry.md>)

### AI overview

A tutorial on error handling and resiliency for LLM-powered applications. It covers failures such as unavailable networks, rejected requests, invalid JSON, hallucinations, slow responses, timeouts, retries, fallbacks, circuit breakers, rate limiting, queues, concurrency control, safe tool calls, and response streaming.

### Source excerpt

Apart from normal processing, the application also sends data to a large language model (LLM). It then uses the model's response to carry out a task.

## How Databases Keep Their Sanity with Concurrency Control

DevFeed: [How Databases Keep Their Sanity with Concurrency Control](<https://devfeed.tech/articles/how-databases-keep-their-sanity-with-concurrency-control-17989.md>)

Original publisher: [Read original article](<https://blog.bytebytego.com/p/how-databases-keep-their-sanity-with>)

Author: ByteByteGo

Published: 2026-09-03T15:31:17Z

Content type: article

Language: en

Sources: [ByteByteGo](<https://devfeed.tech/sources/bytebytego.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrency-control](<https://devfeed.tech/tags/concurrency-control.md>), [databases](<https://devfeed.tech/tags/databases.md>)

### AI overview

The article introduces how databases handle bugs related to concurrency control, but the supplied evidence does not provide the specific methods or findings discussed.

### Source excerpt

So how do we handle such bugs? This is what we are going to try to answer in this article.

## Optimistic Locking Overview

DevFeed: [Optimistic Locking Overview](<https://devfeed.tech/articles/optimistic-locking-overview-26514.md>)

Original publisher: [Read original article](<https://medium.com/engineering-housing/optimistic-locking-overview-6b30315e759b?source=rss----3a69e32e2594---4>)

Author: somesh sharma

Published: 2025-06-19T09:02:40Z

Content type: tutorial

Language: en

Sources: [Housing.com](<https://devfeed.tech/sources/housing-com.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrency-control](<https://devfeed.tech/tags/concurrency-control.md>), [database](<https://devfeed.tech/tags/database.md>), [databases](<https://devfeed.tech/tags/databases.md>), [isolation-level](<https://devfeed.tech/tags/isolation-level.md>), [locks](<https://devfeed.tech/tags/locks.md>), [optimistic-locking](<https://devfeed.tech/tags/optimistic-locking.md>), [retry](<https://devfeed.tech/tags/retry.md>), [sql](<https://devfeed.tech/tags/sql.md>), [stateless](<https://devfeed.tech/tags/stateless.md>), [transaction-management](<https://devfeed.tech/tags/transaction-management.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

### AI overview

An overview of optimistic locking as a concurrency-control mechanism for database transactions. It explains how version columns detect conflicting updates, when optimistic locking is suitable, and when transaction isolation may make it unnecessary.

### Source excerpt

Optimistic locking is a concurrency control mechanism where we assume that multiple transactions can safely access data without conflict, allowing them to proceed without locking the data upfront. Unlike pessimistic locking, where resources are locked to avoid conflicts, optimistic locking allows transactions to proceed without locks and checks for conflicts only when updating the data. If a conflict is detected (e.g., another transaction has already modified the data), the operation fails, and you can retry it. When Should You Use Optimistic Locking? Optimistic locking is ideal for use in scenarios where: Low contention exists: If it's unlikely that multiple users or processes will try to update the same data at the same time, optimistic locking is a good fit. This is especially true in systems where most operations involve reading data rather than writing it. High read-to-write ratio: If your application is mostly about reading data and writing happens less frequently, optimistic locking helps avoid the overhead of locking rows during reads. Non-critical updates: In cases where it's okay to retry a failed update without much impact, optimistic locking is a good choice. When conflicts arise, either the user or the system can simply retry. Stateless operations: Optimistic locking is suitable in stateless environments where holding onto locks across multiple requests or sessions isn't feasible. Long-running transactions: If your transactions take a long time to complete, holding locks during the entire process isn't feasible. Optimistic locking provides flexibility while still maintaining data integrity. How Optimistic Locking Works in Databases In databases, optimistic locking is usually implemented with a version column. Each row in the database has a version field (like a number or timestamp) that gets updated whenever the row is modified. When updating a record, the database checks if the version in the database matches the version the transaction originally read

## MVCC and serializability in HyPer

DevFeed: [MVCC and serializability in HyPer](<https://devfeed.tech/articles/mvcc-and-serializability-in-hyper-39630.md>)

Original publisher: [Read original article](<https://www.gauravsarma.com/posts/2024-11-06_MVCC-and-serializability-in-HyPer-564430884c9a>)

Published: 2024-11-06T00:00:00Z

Content type: article

Language: en

Sources: [Gaurav Sarma's Blog](<https://devfeed.tech/sources/gaurav-sarma-s-blog.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [locking](<https://devfeed.tech/topics/locking.md>), [Deadlock](<https://devfeed.tech/topics/deadlock.md>), [processing](<https://devfeed.tech/topics/processing.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrency-control](<https://devfeed.tech/tags/concurrency-control.md>), [database](<https://devfeed.tech/tags/database.md>), [deadlock](<https://devfeed.tech/tags/deadlock.md>), [locking](<https://devfeed.tech/tags/locking.md>), [mvcc](<https://devfeed.tech/tags/mvcc.md>), [processing](<https://devfeed.tech/tags/processing.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

### AI overview

This article explains Multi-Version Concurrency Control (MVCC), contrasts it with Two-Phase Locking, and introduces MVCC patterns and techniques used in HyPer. It discusses locking phases, deadlocks, cascading rollbacks, and concurrency limitations.

### Source excerpt

. [MVCC and Serializability in HyPer](mvcc-and-serializability-in-hyper-cover...

## Safe and scalable signal handling in Temporal Workflows

DevFeed: [Safe and scalable signal handling in Temporal Workflows](<https://devfeed.tech/articles/safe-and-scalable-signal-handling-in-temporal-workflows-35963.md>)

Original publisher: [Read original article](<https://temporal.io/blog/robust-message-handlers>)

Author: Drew Hoskins

Published: 2024-10-15T16:00:00Z

Content type: article

Language: en

Sources: [Temporal Blog](<https://devfeed.tech/sources/temporal-blog.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Developer experience](<https://devfeed.tech/topics/developer-experience.md>), [SDKs](<https://devfeed.tech/topics/sdks.md>), [Go Language](<https://devfeed.tech/topics/go-language.md>), [Python](<https://devfeed.tech/topics/python.md>), [AI Chat](<https://devfeed.tech/topics/ai-chat.md>)

Tags: [announce](<https://devfeed.tech/tags/announce.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrency-control](<https://devfeed.tech/tags/concurrency-control.md>), [developer-experience](<https://devfeed.tech/tags/developer-experience.md>), [go](<https://devfeed.tech/tags/go.md>), [handler](<https://devfeed.tech/tags/handler.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [python](<https://devfeed.tech/tags/python.md>), [race-conditions](<https://devfeed.tech/tags/race-conditions.md>), [safety](<https://devfeed.tech/tags/safety.md>)

### AI overview

This article explains how Signal and Update handlers let callers interact with Temporal Workflows, focusing on concurrency problems, message-processing styles, and improvements intended to make handlers safer and easier to use.

### Source excerpt

Avoid race conditions in Temporal Workflows. Learn how new Signal and Update handler tools improve safety, initialization, and concurrency control.

## Optimistic locking pitfalls

DevFeed: [Optimistic locking pitfalls](<https://devfeed.tech/articles/optimistic-locking-pitfalls-27269.md>)

Original publisher: [Read original article](<https://blog.pchudzik.com/201704/optimistic-locking/>)

Published: 2017-04-27T00:00:00Z

Content type: tutorial

Language: en

Sources: [Paweł Chudzik](<https://devfeed.tech/sources/pawe-chudzik.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [.NET 11 Preview 7](<https://devfeed.tech/topics/net-11-preview-7.md>)

Tags: [concurrency-control](<https://devfeed.tech/tags/concurrency-control.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [hibernate](<https://devfeed.tech/tags/hibernate.md>), [java](<https://devfeed.tech/tags/java.md>), [jpa](<https://devfeed.tech/tags/jpa.md>), [locking](<https://devfeed.tech/tags/locking.md>), [optimistic-locking](<https://devfeed.tech/tags/optimistic-locking.md>), [pitfalls](<https://devfeed.tech/tags/pitfalls.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

### AI overview

This article explains optimistic locking as a concurrency-control technique and examines how plain SQL and JPA/Hibernate version checks prevent one user from unintentionally overwriting another user's changes.

### Source excerpt

Optimistic locking is concurrency control method that allows to execute multiple transactions simultaneously as long as they don't interfere which each other. That's definition from wikipedia. You probably already know that Hibernate supports optimistic locking and all you have to do in order to implement optimistic locking in you app is to add @Version on number or timestamp field and you are good to go. Right? Read more

## Single Writer Principle

DevFeed: [Single Writer Principle](<https://devfeed.tech/articles/single-writer-principle-13617.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2011/09/single-writer-principle.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2011-09-22T14:24:00Z

Content type: tutorial

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [Scalability](<https://devfeed.tech/topics/scalability.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Operating system](<https://devfeed.tech/topics/operating-system.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [cpu](<https://devfeed.tech/topics/cpu.md>)

Tags: [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrency-control](<https://devfeed.tech/tags/concurrency-control.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [cycles](<https://devfeed.tech/tags/cycles.md>), [intel](<https://devfeed.tech/tags/intel.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [latency](<https://devfeed.tech/tags/latency.md>), [performance](<https://devfeed.tech/tags/performance.md>), [processor-affinity](<https://devfeed.tech/tags/processor-affinity.md>), [scalability](<https://devfeed.tech/tags/scalability.md>)

### AI overview

The article explains that contention among multiple writers is a major scalability limitation. It compares mutual exclusion, typically implemented with locks, with optimistic concurrency control, describing how contention can increase queuing, latency, and reduce throughput.

### Source excerpt

When trying to build a highly scalable system the single biggest limitation on scalability is having multiple writers contend for any item of data or resource. Sure, algorithms can be bad, but let's assume they have a reasonable Big O notation so we'll focus on the scalability limitations of the systems design. I keep seeing people just accept having multiple writers as the norm. There is a lot of research in computer science for managing this contention that boils down to 2 basic approaches. One is to provide mutual exclusion to the contended resource while the mutation takes place; the other is to take an optimistic strategy and swap in the changes if the underlying resource has not changed while you created the new copy. Mutual Exclusion Mutual exclusion is the means by which only one writer can have access to a protected resource at a time, and is usually implemented with a locking strategy. Locking strategies require an arbitrator, usually the operating system kernel, to get involved when the contention occurs to decide who gains access and in what order. This can be a very expensive process often requiring many more CPU cycles than the actual transaction to be applied to the business logic would use. Those waiting to enter the critical section, in advance of performing the mutation must queue, and this queuing effect (Little's Law) causes latency to become unpredictable and ultimately restricts throughput. Optimistic Concurrency Control Optimistic strategies involve taking a copy of the data, modifying it, then copying back the changes if data has not mutated in the meantime. If a change has happened in the meantime you repeat the process until successful. This repeating of the process increases with contention and therefore causes a queuing effect just like with mutual exclusion. If you work with a source code control system, such as Subversion or CVS, then you are using this algorithm every day. Optimistic strategies can work with data but do not work so wel