Коллекция вопросов ❓ на собеседовании в C# 🍧

Обзор вопросов по языка програмиированию C# и технологии NET

---

Project maintained by Dvurechensky-Docs Hosted on GitHub Pages — Theme by mattgraham

🔒 Какие бывают уровни изоляции транзакций и зачем они нужны?

✨ Оглавление

• ✨ Оглавление
  • 1️⃣ Почему уровни изоляции важны
  • 2️⃣ Основные проблемы, которые решает изоляция
  • 3️⃣ Уровни изоляции (ANSI SQL Standard)
    • a) Read Uncommitted
    • b) Read Committed (по умолчанию в SQL Server)
    • c) Repeatable Read
    • d) Serializable
    • e) Snapshot (SQL Server специфично)
  • 4️⃣ Выбор уровня изоляции
  • 5️⃣ Практические советы для .NET

⬆ Вернуться к главной

---

1️⃣ Почему уровни изоляции важны

Транзакции обеспечивают ACID:

• A — Atomicity (атомарность)
• C — Consistency (согласованность)
• I — Isolation (изоляция)
• D — Durability (надёжность)

Isolation определяет, как изменения одной транзакции видны другим транзакциям.

Без корректной изоляции:

• Возможны грязные чтения (dirty read).
• Возможны неповторяемые чтения (non-repeatable read).
• Возможны фантомные чтения (phantom read).

---

2️⃣ Основные проблемы, которые решает изоляция

Проблема	Пример	Опасность
Dirty read	Транзакция B читает данные, которые транзакция A ещё не зафиксировала и потом откатила	B получает неконсистентные данные
Non-repeatable read	Транзакция B меняет данные между двумя чтениями транзакции A	Чтения A различаются → ошибки логики
Phantom read	Транзакция B вставляет новые строки, которые попадают в выборку транзакции A	A видит «фантомные» строки при повторном SELECT

---

3️⃣ Уровни изоляции (ANSI SQL Standard)

a) Read Uncommitted

• Суть: самая слабая изоляция, транзакция видит незавершённые изменения других транзакций.
• Проблемы: допускает dirty read, non-repeatable read и phantom read.
• Пример:

using var transaction = connection.BeginTransaction(IsolationLevel.ReadUncommitted);

• Особенности:

  • Используется для отчётности, где важна скорость, а данные могут быть «грязными».

• Каверзный момент: SQL Server может не блокировать таблицы → быстро, но ненадёжно.

---

b) Read Committed (по умолчанию в SQL Server)

• Суть: транзакция видит только зафиксированные данные.
• Проблемы: допускает non-repeatable read и phantom read, но нет dirty read.

• Особенности:

  • SQL Server использует блокировки чтения (shared lock).
  • Можно включить Read Committed Snapshot Isolation → уменьшение блокировок через versioning.
• Каверзный момент: многие думают, что Read Committed гарантирует повторяемое чтение — нет.

---

c) Repeatable Read

• Суть: транзакция гарантирует, что все прочитанные данные не изменятся другими транзакциями до конца.
• Проблемы: допускает фантомные строки (новые INSERT могут появиться).

• Особенности:

  • SQL Server ставит shared lock на прочитанные строки до конца транзакции.
• Каверзный момент: блокировки могут увеличить конкуренцию, риск deadlock.

---

d) Serializable

• Суть: самая строгая изоляция, транзакции выполняются так, как если бы они были последовательными.
• Проблемы: минимизирует все аномалии: нет dirty read, non-repeatable read, phantom read.

• Особенности:

  • Используются range-lock для предотвращения фантомных строк.
• Каверзный момент: снижает параллелизм, высокие блокировки → медленные транзакции при большой нагрузке.

---

e) Snapshot (SQL Server специфично)

• Суть: каждая транзакция видит снимок данных на момент её начала.
• Проблемы: нет dirty read, нет non-repeatable read, нет фантомов.

• Особенности:

  • Использует versioning (tempdb хранит старые версии строк).
  • Хорошо подходит для отчётности и параллельных чтений.
• Каверзный момент: высокая нагрузка на tempdb при большом числе изменений.

---

4️⃣ Выбор уровня изоляции

Уровень	Dirty Read	Non-repeatable Read	Phantom Read	Производительность
Read Uncommitted	✅	✅	✅	высокая
Read Committed	❌	✅	✅	средняя
Repeatable Read	❌	❌	✅	ниже
Serializable	❌	❌	❌	низкая
Snapshot	❌	❌	❌	зависит от versioning

Каверзный момент: «повышение» уровня изоляции → блокировки растут, производительность падает, deadlock риск увеличивается.

---

5️⃣ Практические советы для .NET

1. Для Web API / отчётности: часто хватает Read Committed или Snapshot для быстрого чтения.
2. Для банковских транзакций: Serializable или Repeatable Read → консистентность.
3. Для массовых обновлений: избегать Serializable → риск блокировок.
4. EF Core примеры:

using var transaction = await context.Database.BeginTransactionAsync(System.Data.IsolationLevel.RepeatableRead);

1. Deadlock prevention: короткие транзакции, единый порядок захвата ресурсов.

---

⬆ Вернуться к главной

✨Dvurechensky✨