Если вам кажется, что вы понимаете, что такое транзакции - вам кажется.

Несколько лет назад в знаменитом «кабанчике» Клеппмана я прочитала:

"Транзакции оказались главной жертвой" NoSQL БД: "многие базы нового поколения полностью отказались или поменяли значение термина — теперь он стал означать намного более слабый набор функциональных гарантий."

Хм, интересно, подумала я, но тогда не придала этому значения. Позже я начала работать с 389 Directory Server - иерархической БД на протоколе LDAP.

😮И... сюрприз, сюрприз: 😮 в базовой комплектации в ней нет транзакционности в привычном для SQL-разработчика смысле.

Что это значит:

- Как только произошла операция над объектом (в LDAP это ADD, MODIFY, DELETE) и она подтверждена сервером — она фиксируется.
- Нет отката изменений для группы объектов.
- Можно накрутить костылей вокруг changelog, чтобы имитировать транзакцию, но это будет уже backend-код, а не гарантия от самой БД.

При более детальном разборе оказалось, что в каком-то виде транзакционность (а точнее часть A из ACID) всё же есть, если речь о нескольких изменениях в рамках одной команды, обращённой к одному объекту.

В Пример 1, это обрабатывается как единая операция: либо применяется всё, либо ничего.

 в группе Editors
ADD UserA, UserB  
DELETE UserX, UserY  

С этого момента жить стало проще… до тех пор, пока ко мне не принесли пачку запросов с неконсистентными данными, которые такими быть не долждны были (в нашем понимании).

Причина в том, что к одному объекту можно атомарно обратиться по-разному:

Как в примере 1, или же сделать те же действия, но двумя отдельными командами (пример 2, каждое объявление группы начинает новую операцию):

в группе Editors
ADD UserA, UserB
в группе Editors
DELETE UserX, UserY

При работе на одном сервере: в первом случае атомарность гарантируется на уровне операции, во втором за счет транзакции уровня backend-хранилища (DBTxn). В целом зная об этом, у нас частенько встречались оба варианта операций.

⚠️Вот только⚠️, при репликации каждая команда получает свой CSN (номер изменения) и всегда выполняется отдельно. В результате в Примере 2 первая операция может примениться, а вторая - нет. Хотя на одном сервере, они всегда выполняются вместе.

Когда, казалось бы, я уже понимаю этим важные моменты, мне пришлось столкнуться с RFC 5805 (LDAP Transactions), который открывает перед LDAP возможности транзакционности при использовании специальных патчей. Но это уже совсем другая история.

Так что, если вы уверены, что уже хорошо разбираетесь в транзакциях, но работали только с реляционными СУБД, вас ждёт немало сюрпризов.

💬 Ну а те кто уже хлебнул разных систем, поделитесь с какой «недо»-транзакционностью сталкивались? К чему это приводило? Что было самым необычным?

Участвую в конкурсе #продолжи_мысль_SE от @systems_education

#LDAP #транзакции #СУБД