Ответ
Read Committed — уровень изоляции транзакций, который гарантирует, что транзакция видит только зафиксированные данные других транзакций.
Гарантии: ✅ Защита от "грязного" чтения (Dirty Read) — нельзя прочитать незафиксированные изменения ❌ Нет защиты от неповторяемого чтения (Non-repeatable Read) ❌ Нет защиты от фантомного чтения (Phantom Read)
Пример проблемы с неповторяемым чтением:
-- Транзакция 1
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT balance FROM accounts WHERE id = 1; -- Возвращает 100
-- Транзакция 2 (параллельно)
UPDATE accounts SET balance = 200 WHERE id = 1;
COMMIT;
-- Транзакция 1 (продолжение)
SELECT balance FROM accounts WHERE id = 1; -- Теперь возвращает 200!
COMMIT;Особенности в разных СУБД:
- PostgreSQL: уровень по умолчанию, использует MVCC
- Oracle: уровень по умолчанию, использует откаты (undo segments)
- SQL Server: требует блокировок для предотвращения грязного чтения
Установка в JDBC:
connection.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);Когда использовать:
- Большинство OLTP-приложений
- Когда допустимы незначительные расхождения в данных
- Для баланса между согласованностью и производительностью
Ответ 18+ 🔞
А, ну вот, слушай, смотри, сейчас я тебе про Read Committed так расскажу, что ты, блядь, офигеешь. Это ж самый, сука, распространённый уровень изоляции, как хлеб с маслом, его везде суют по умолчанию, и не просто так!
Представь себе: сидит транзакция, читает себе данные. И тут, блядь, главный принцип — она видит только то, что уже закоммитили другие. То есть, пока какой-то чувак там UPDATE'ит строку и не нажал COMMIT — ты эту ебучую правку не увидишь. Защита от грязного чтения, ёпта! Это как не видеть, пока сосед по комнате не вынес ведро — пока не вынес, вонь есть, но ты её не чувствуешь, красота.
Но вот в чём, сука, подвох, и он жирный! Защищает он только от этой вони, а от остального — нихуя. Нет тут никакой защиты от «неповторяемого чтения» и «фантомов». Сейчас на пальцах, блядь.
Вот смотри, код, не трогаю его, он святой:
-- Транзакция 1
BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT balance FROM accounts WHERE id = 1; -- Возвращает 100
-- Транзакция 2 (параллельно)
UPDATE accounts SET balance = 200 WHERE id = 1;
COMMIT;
-- Транзакция 1 (продолжение)
SELECT balance FROM accounts WHERE id = 1; -- Теперь возвращает 200!
COMMIT;Видишь, в чём пиздец? Первый раз прочитал — 100. Пока он там думал, второй чувак пришёл, бабки спиздил, то есть, обновил баланс на 200 и зафиксировал. Первый чувак снова читает — а у него уже 200! Он, блядь, в рамках одной своей же транзакции два разных значения получил! Это и есть «неповторяемое чтение», ёбаный насос. Данные под ногами разъехались.
А про «фантомы» я молчу — это когда строки новые из ниоткуда возникают или старые в никуда пропадают, пока твоя транзакция жива. Read Committed на это тоже плевать хотел, смотрит в книгу — видит фигу.
А теперь, сука, самое интересное — как они это реализуют! Тут, блядь, разброд и шатание.
- PostgreSQL — умница, у него там MVCC, версионность. Он тебе просто старую версию строки из снапшота подсовывает, пока другая транзакция не закоммитилась. Красота, блокировок на чтение нет вообще.
- Oracle — тоже красавчик, по умолчанию тот же Read Committed, но через свои «сегменты отката» работает. Хуй пойми как, но работает.
- SQL Server — а вот этот, сука, любитель блокировок. Чтобы тебе грязное чтение не подсунули, он будет ставить блокировки на строки, которые ты читаешь. Может и до дедлока доиграться, если неаккуратно.
Воткнуть это в JDBC — проще пареной репы, один хуй не разберёшься:
connection.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);Так когда же его использовать-то, блядь? Да в 90% случаев! Серьёзно. Для всяких OLTP-приложений, где перфоманс важен, а мелкие расхождения в данных (типа, прочитал 100, а через полсекунды уже 200) — не конец света. Идеальный баланс, ёпта, между «всё чётко» и «летает быстро». Если, конечно, тебе не нужно, чтобы данные были стабильны, как скала, на протяжении всей транзакции — тогда вали, блядь, на уровень выше, на Repeatable Read, и не морочь голову.