Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update distributed-transactions-ysql.md #23580

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update distributed-transactions-ysql.md #23580

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 2 additions & 4 deletions docs/content/preview/explore/transactions/distributed-transactions-ysql.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,9 +156,7 @@ Each update performed as a part of the transaction is replicated across multiple

### Concurrency control

[Concurrency control](../../../architecture/transactions/concurrency-control/) in databases ensures that multiple transactions can execute concurrently while preserving data integrity. Concurrency control is essential for correctness in environments where two or more transactions can access the same data at the same time. The two primary mechanisms to achieve concurrency control are optimistic and pessimistic.

YugabyteDB currently supports optimistic concurrency control, with pessimistic concurrency control being worked on actively.
[Concurrency control](../../../architecture/transactions/concurrency-control/) in databases ensures that multiple transactions can execute concurrently while preserving data integrity. Concurrency control is essential for correctness in environments where two or more transactions can access the same data at the same time.

## Transaction options

Expand Down Expand Up @@ -212,4 +210,4 @@ As in PostgreSQL, the `DEFERRABLE` transaction property is not used unless the t

When all three of these properties (`SERIALIZABLE`, `DEFERRABLE`, and `READ ONLY`) are set for a transaction, the transaction may block when first acquiring its snapshot, after which it can run without the typical overhead of a `SERIALIZABLE` transaction and without any risk of contributing to or being canceled by a serialization failure.

This mode is well-suited for long-running reports or backups without impacting or being impacted by other transactions.
This mode is well-suited for long-running reports or backups without impacting or being impacted by other transactions.