fix typo

ydb/docs/ru/core/contributor/datashard-distributed-txs.md

@@ -100,7 +100,7 @@ DataShard обрабатывает сообщения `TEvTxProcessing::TEvPlanS
 
 В отличие от персистентных транзакций, волатильные транзакции хранятся только в памяти, пропадают на рестартах шарда, но при этом обязаны гарантировать, что транзакция будет либо закоммичена на всех участниках, либо оперативно отменена на всех участниках в случае ошибки на любом их них. Их преимущество при этом, что они не разделяются на длительные фазы чтения, ожидания и выполнения, а атомарно выполняются в единственной фазе выполнения за 1RTT стораджа на пути от начала запроса до ответа клиентам, при этом они чаще всего не задерживаются в очереди выполнения и позволяют увеличивать пропускную способность шардов. Благодаря тому, что любой шард имеет возможно отменить транзакцию в любой момент, это также уменьшает недоступность шардов во время изменения партиционирования или выполнения схемных операций.
 
-В основе волатильных транзакций лежит поддержка [персистентных незакомиченных изменений](localdb-uncommitted-txs.md) в локальной базе. На фазе выполнения все эффекты записываются как незакомиченные (при этом используется глобально уникальный `TxId` распределённой транзакции), с добавлением транзакции в [VolatileTxManager](https://github.com/ydb-platform/ydb/blob/1f1b84d1d160a2b1cfe4298b271c0078ec1602b1/ydb/core/tx/datashard/volatile_tx.cpp#L439) в состоянии ожидания решения о коммите от всех участников. Успешный ответ отправляется клиенту только после того как эффекты нашёжно записаны, и все участники приняли решение о коммите. Последующие чтения используют `TxMap` чтобы видеть ещё ожидающие изменения, но проверяют их статус с помощью `TxObserver`. Если оказывается, что результат чтения зависит от волатильных изменений в состоянии ожидания, то такая операция подписывается на принятие решения о коммите волатильной транзакции и в конечном итоге перезапускается (либо прочитав теперь уже закомиченные изменения, либо пропустив их после отмены).
+В основе волатильных транзакций лежит поддержка [персистентных незакомиченных изменений](localdb-uncommitted-txs.md) в локальной базе. На фазе выполнения все эффекты записываются как незакомиченные (при этом используется глобально уникальный `TxId` распределённой транзакции), с добавлением транзакции в [VolatileTxManager](https://github.com/ydb-platform/ydb/blob/1f1b84d1d160a2b1cfe4298b271c0078ec1602b1/ydb/core/tx/datashard/volatile_tx.cpp#L439) в состоянии ожидания решения о коммите от всех участников. Успешный ответ отправляется клиенту только после того как эффекты надёжно записаны, и все участники приняли решение о коммите. Последующие чтения используют `TxMap` чтобы видеть ещё ожидающие изменения, но проверяют их статус с помощью `TxObserver`. Если оказывается, что результат чтения зависит от волатильных изменений в состоянии ожидания, то такая операция подписывается на принятие решения о коммите волатильной транзакции и в конечном итоге перезапускается (либо прочитав теперь уже закомиченные изменения, либо пропустив их после отмены).
 
 Наличие ещё незакомиченных и не отменённых волатильных транзакций накладывает ограничения на выполнение слепых операций на шарде. Из-за того, что незакомиченные изменения в локальной базе должны обязательно коммититься в том же порядке, в котором они происходили по каждому ключу, а информация о ключах транзакции не остаётся в памяти после её выполнения, DataShard вынужден делать чтение по ключу перед каждой записью для поиска конфликтов. Эти конфликты могут возникать как из-за незакомиченных изменений в рамках оптимистичных блокировок (в этом случае такие оптимистичные блокировки ломаются), так и принадлежать ещё ожидающим волатильным транзакциям. Чтобы не блокировать запись на время ожидания, даже не волатильная операция может переключиться на волатильный коммит. Для этого при необходимости выделяется `GlobalTxId` (уникальный в рамках кластера идентификатор транзакции, необходимые в случае отсутствия `TxId` в запросе, например `BulkUpsert`), а запись изменений по конфликтующим ключам переходит на волатильный коммит. Изменения при этом записываются как незакомиченные с указанием `GlobalTxId`, а в `VolatileTxManager` транзакция добавляется без указания других участников, и сразу оказывается закомиченной. Такие транзакции не блокируют последующие чтения, и после того как нижестоящие транзакции закоммитятся или отменятся, эти изменения также будут закоммичены в локальной базе.