AndrewVLЛадно) может потом что щёлкнет в голове и все с сне. На место.

Приведу ещё один пример. (Read committed) Есть длинная полка с книгами. Библиотекарь решил с неё убрать пару Книг , но сначала решил попить чая(первая транзакция) А тут простой читатель так же read commited решил эти книги ну например пересчитать. Идёт по полке, считает . Насчитал уже 1000 книг. И тут библиотекарь проснулся и решил забрать две книги и пойти домой (commit ). В итоге читатель насчитал 1000 книг . А на момент его commit на полке все ж 998 книг . И пока он не пересчитаете не будет иметь достоверной инфы.
Все в стандартной read commited. Ну по идее так и должно быть. Только повторный пересчёт даст достоверный результат.

Душа моя. А по жизни, не в программе, какой есть способ узнать, что за спиной у тебя, считающего, кто-то не потырил уже сосчитанную книжку с полки? Святой Дух обычно сильно занят более значимыми и для человечества и для Мироздания в целом проблемами и кричать - оглянись! - ему каждому считателю некогда. Так же и в ей, в программе. Теперь - а что такое достоверная инфа в нашем непрерывно и быстро меняющемся мире? Она может быть достоверной только на какой-то момент времени. Весь вопрос - на какой. И вот тут-то и появляется Диавол, кроющийся, как известно, в деталях.

Что есть коммит. В Firebird вообще нет понятия текущего состояния ни записи, ни отношения (таблицы в целом, ибо она состоит из записей). Есть цепочки версий записи и транзакции видят те версии, которые им положено исходя из уровня изоляции. Не во всех SQL-серверах решение проблемы достоверности на некоторый момент такое, потому и говорю - в Firebird. Зачем так?

Дело в том, что в реляционной модели представление описаний объектов реального мира, как правило, размазано по нескольким таблицам, содержащим описания взаимосвязанных сущностей, составляющих этот объект. То есть, описание объекта - это не запись, а гроздь записей, и частенько при изменении одной надо что-то поменять и в других, и только тогда описание объекта будет непротиворечивым и целостным. Классический упрощённый бытовой пример - накладная. Заголовок и состав. Это не считая справочников, на которые они ссылаются. Транзакция меняет состав (изменяет количество, добавляет, удаляет) и финальным аккордом транслирует суммарные данные в заголовок - читающие в это время видят старое состояние. Целостное. Всё сделала, говорит - всё, пи... тьфу, коммит. С этого момента read_commited транзакции видят это состояние объекта, хотя в то же самое время его может менять неспешно-постепенно другая пишущая транзакция. А вот concurrency транзакции всё равно видят то состояние, которое было на момент их старта. Зачем так?

Вернёмся к примитиву с накладной. Наша пишущая транзакция добавила запись в состав, подправила суммарный тоннаж в заголовке, в это время читающая read_commited прочитала заголовок (с данными предыдущей версии), наша закоммитилась, читающая прочитала состав и фигню получила практицки. В заголовке 10 кило, в составе 12.



А читающая concurrency получила состояние 10 и 10. Целостное на момент её старта. Не актуальное в сию секунду? Говно вопрос. Если пользователь позырил и успокоился, то какая разница, а если полезет менять - получит отлуп, в смысле конфликт - данные, любые, в записи в любой таблице, которую эта транзакция попытается изменить, были изменены после её старта. Перечитает и скажет - аааа... И отчёты на больших объёмах данных на какой-то момент времени тоже делаются в concurrency, чтобы они были непротиворечивы что на уровне вглыбь по каждой позиции, что в длину по списку позиций на момент времени начала их, отчётов в смысле, составления. Поменять ведь могут за время работы не только сзади читающей головки, но и впереди, что ценность отчёта сводит к нулю - непонятно какая позиция к какому моменту времени относится. Слова "прямо сейчас" - бессмыслица по определению в многопользовательской среде.

Вернёмся к нашим баранам, в смысле чтению списка. А какая разница, что он не совсем соответствует сиюминутному состоянию? Он нужен зачем? Просто так - да и фиг с ним. Выбрать позицию и поработать с ней? Так надо стартовать транзакцию для работы с этой позицией и перечитать её первым шагом, увидеть актуальное на этот момент состояние. Или ни хрена не увидеть если к моменту принятия решения на редактирование эту позицию удалили и закоммитили удаление. И дальше при внесении изменений получить отлуп если кто-то полез в эту же позицию параллельно и успел что-то поменять первым. Или принять меры к тому, чтобы он этого сделать не смог. Что удобно, но чревато. Но это уже другая история.

Ну что, все мозги разбил на части, все извилины заплёл? :)