Ні, я не думаю, що ваші умови призводять до того, що система, яку ми повинні вважати серіалізаційною, повинна бути прийнятою.
Ізоляція знімків - це техніка, яка забезпечує транзакцію бачити однаковий набір даних протягом усієї транзакції. Ізоляція знімків дає певні гарантії, але не визначає всіх характеристик, необхідних для розуміння того, як реально працюють транзакції (якщо тільки ми не вирішимо співвідносити ізоляцію знімків та MVCC).
Ізоляція знімків найчастіше реалізується за допомогою MVCC, Multi Version Consistency Control. MVCC визначає більш детальну інформацію про транзакції в контексті їхніх знімків: це означає, що вони потребують ізоляції лише тоді, коли записують конфлікт (лише розташування або розташування + значення, залежно від реалізації). MVCC надає модель розслабленої послідовності та страждає від перекосу письма.
Моделі з розслабленою консистенцією важко зрозуміти, оскільки вони схожі на гібрид між відсутністю ізоляції та повною ізоляцією.
Отже, давайте спочатку почнемо із суворої моделі паралельності. Дві транзакції повинні бути ізольовані один від одного, якщо один записує будь-які дані, які інший або читає, або записує (і навпаки ...).
Коли ми не знаємо, чому транзакція зчитує дані, ми маємо припустити, що зчитування іншого значення може змінити поведінку залученого клієнта, тому умова транзакцій, що перекриваються, вказує на ізоляцію. Без ізоляції при зчитуванні несвіжих даних на знімку можна легко виявити розслаблену послідовність, ще одним терміном для якого є непослідовність, тобто помилка.
Нам потрібно лише врахувати точні дані, прочитані або записані транзакціями, будь-які дані поза цим набором не повинні розглядатися. Однак важливо усвідомити, що, коли ми говоримо про дані, прочитані транзакцією, ми обов'язково повинні включати будь-які і всі "мета" дані (а також дані та метадані, прочитані мета-операціями, такими як перевірка обмежень). Прикладами метаданих / мета-операцій є: ідентифікація унікального нового первинного ключа; інша - сума цілої колонки; інше - шукати щось, а не знаходити його; діапазон пошуку або сум. Це стосується коментаря @ Matthew щодо запобігання дублікатів, а також відповіді @Tersosauros, в якій він вважає стан.
Наприклад, це означає, що дві транзакції перекриваються (вимагають ізоляції), коли вони обидва вставляють рядок (припускаючи унікальне обмеження первинного ключа), оскільки перевірка обмеження ключа є синонімом читання всього стовпця первинного ключа. Як інший приклад, пошук чогось і знаходження цього - це як читання одного значення, однак, не знаходження його, як перегляд кожного значення в стовпці.
MVCC захищає лише від перекриття чи конфліктуючих записів, але не захищає від читання (якщо також це не було написано цією транзакцією). Таким чином, щоб отримати помилку узгодженості в MVCC, все, що нам потрібно зробити, - це прочитати те, що змінюється іншою транзакцією (де інша транзакція відбувається після того, як зроблений знімок попереднього, але здійснюється перша), а інша транзакція продовжує використовувати несвіжі дані та приймає будь-яке рішення по-іншому на основі цих затхлих даних порівняно з тим, що було б зроблено сучасними даними. Це легше викликати, ніж ти думав.
Розслаблена послідовність - це ще один спосіб сказати про потенційно непослідовну або схильну до помилок. (Розслаблену послідовність не слід плутати з можливою послідовністю, що є іншою популярною формою помилок, схильною до "NoSQL".)
Що стосується вашого запитання, коли ви говорите, що транзакції ніколи не повинні охоплювати більше одного об’єкта, це має стосуватися як читання, так і запису, а також метаданих (і метаоперацій), включаючи перевірку узгодженості, агрегації цілих стовпців, перевірки відсутності, пошук діапазону тощо. .: якщо так, то поки що так добре.
Однак ...
Я розумію, що ви використовуєте запитання про те, що ви використовуєте ізоляцію знімків (MVCC) на окремих об'єктах (скажімо, а не на блокування об'єктів). (Ви також згадуєте CAS; я чув про порівняння і заміну, і, тест і встановлення, але не перевірка і встановлення, хоча я припускаю, що це схоже).
Ваше запитання записує мені, що "об'єкти" мають більше одного поля, інакше умови запитання були б непотрібними.
Тому, оскільки у ваших об'єктів, що обробляються моментально / MVCC, є більше одного поля, ви схильні писати перекоси в межах одного об’єкта. Якщо дві транзакції оновлюють один і той же об'єкт одночасно, можна прочитати поле значення об'єкта, унеможене за рахунок одночасних інших транзакцій на тому самому об'єкті, і продовжувати, не знаючи, таким чином, потенційної непослідовності (ака помилки).
Ви можете замість цього заблокувати об'єкт, що не дозволить двом транзакціям (для оновлення) навіть дивитись на той самий об’єкт, якщо інша транзакція вже була в процесі цього.
Я вважаю, що альтернативну форму ізоляції знімків можна зробити, не використовуючи лише порівняну модель порівняння запису набору MVCC. Таким чином, ви можете (алгоритмічно) просувати набір порівняння з лише для запису, щоб включити також набір для читання. Тоді дві транзакції, що оновлюють один і той же об'єкт, не зможуть викликати перекос запису (оскільки той, який намагається зробити пізніше, буде скасовано). Я думаю, що це може бути відповідним рішенням проблеми, яку ви описуєте, адже ви вже отримуєте більшу частину вигоди, яку придбав би нам MVCC, виключаючи трансакції з кількома об'єктами.
(Нам потрібно враховувати лише точні та конкретні елементи / поля, прочитані чи записані, але ми повинні включати такі, які читаються як метадані, потенційно під час мета-операцій для запобігання перекосу запису (тобто помилки). Якщо ми видалимо читання читання з набору порівняння або ми не враховуємо метадані (потенційно використовувані мета-операціями), тоді у нас є модель, яка дозволить помилку.)