❓ Какие уровни изоляции транзакций существуют?

1️⃣ Read Uncommitted - транзакция может читать изменения, которые ещё не зафиксированы другой транзакцией.
❗️ Возможна проблема грязного чтения (dirty read).

2️⃣ Read Committed - транзакция видит только зафиксированные изменения.
❗️ Возможна проблема неповторяющегося чтения (non-repeatable read).

3️⃣ Repeatable Read - транзакция видит одни и те же данные при повторных чтениях.
❗️ Возможна проблема фантомных чтений (phantom reads), когда другая транзакция добавляет новые строки, влияющие на ваш запрос.

4️⃣ Serializable - транзакции выполняются последовательно, как если бы они шли одна за другой, что исключает фантомные чтения.
❗️ Самый медленный уровень.

❓ Что такое dirty read в контексте работы с БД?

Dirty read (грязное чтение) — это ситуация, когда одна транзакция считывает данные, которые были изменены другой транзакцией, но ещё не зафиксированы. Если вторая транзакция откатится, то данные, которые считала первая транзакция, окажутся недействительными.

📌 Пример:

- Транзакция A обновляет баланс счета: UPDATE accounts SET balance = 1000 WHERE id = 1;
- Транзакция A не фиксирует изменения (COMMIT), а баланс временно обновлён.
- Транзакция B считывает баланс: SELECT balance FROM accounts WHERE id = 1;
- Если транзакция A откатится (ROLLBACK), то данные, которые считала транзакция B, окажутся некорректными.

Dirty read возможен только при уровне изоляции READ UNCOMMITTED. На практике этот уровень редко используется, так как приводит к нестабильности данных. Уровни изоляции вроде READ COMMITTED и выше предотвращают грязные чтения, делая транзакции более надёжными.

❓ Что такое non-repeatable read в контексте работы с БД?

Non-repeatable read (неповторяемое чтение) — это ситуация, когда одна транзакция считывает одни и те же данные дважды в рамках одной транзакции, но получает разные результаты из-за изменений, внесённых другой транзакцией между этими чтениями.

📌 Пример:

- Транзакция A считывает данные:
SELECT balance FROM accounts WHERE id = 1;
Результат: balance = 1000.
- Транзакция B обновляет те же данные и фиксирует изменения:
UPDATE accounts SET balance = 1500 WHERE id = 1; COMMIT;.
- Транзакция A снова считывает данные в рамках той же транзакции:
SELECT balance FROM accounts WHERE id = 1;
Результат: balance = 1500.

В результате данные, полученные Транзакцией A, отличаются в первом и втором чтении.

Non-repeatable read возможен на уровне изоляции READ COMMITTED. Чтобы предотвратить такие ситуации, используется уровень REPEATABLE READ, который гарантирует неизменность данных, считанных транзакцией, до её завершения.

❓ Что такое проблема N+1 в JPA и как её избежать?

Проблема N+1 возникает, когда для выборки данных из базы выполняется 1 основной запрос и N дополнительных запросов для каждой сущности, связанной с основной. Это происходит из-за ленивой загрузки (LAZY) связанных данных, когда каждая связанная сущность запрашивается отдельно.

📌 Пример:

List<Department> departments = departmentRepository.findAll();
for (Department department : departments) {
    System.out.println(department.getEmployees().size());
}

- Выполняется запрос для получения всех Department (1 запрос).
- Для каждого департамента выполняется отдельный запрос для загрузки employees (N запросов).
- Итого: 1 + N запросов вместо оптимального 1-2.

💡 Как избежать?

▪️ Использовать JOIN FETCH
▪️ Использовать EntityGraph
▪️ Настроить @Fetch(FetchMode.SUBSELECT) (Hibernate)

❓ Что такое Spring Bean?

❌ Неверно: Весенняя фасоль

✔️ Правильный ответ: Spring Bean — это объект, управляемый контейнером Spring IoC (Inversion of Control). Бины представляют собой ключевые компоненты приложения, которые создаются, настраиваются и управляются Spring Framework.

🛠 Основные характеристики Spring Bean:

- Управление жизненным циклом:
Контейнер отвечает за создание, инициализацию и уничтожение бина.
- Конфигурация:
Бины можно определять с помощью аннотаций (@Component, @Service, @Repository, @Bean) или XML-конфигурации.
- Инъекция зависимостей (DI):
Контейнер автоматически внедряет зависимости, требуемые для работы бина.

💡 Как избежать катастрофы при переходе на PostgreSQL: руководство по спасению базы данных

Переход на PostgreSQL — это не просто замена одного инструмента другим. Неправильный подход может привести к потере данных, снижению производительности и длительным простоям. Особенно это касается хранимых процедур: различия между PL/pgSQL и языками, такими как PL/SQL или T-SQL, могут вызывать ошибки, которые сложно обнаружить заранее.

Если вы хотите узнать, как избежать этих проблем, правильно спланировать переход и не потерять производительность, ознакомьтесь с важными советами и готовыми решениями, которые сделают миграцию безопасной и эффективной. 🚀

🔗 Читать статью
🔗 Зеркало

❓ Что такое phantom reads в контексте работы с БД?

Phantom reads (фантомные чтения) — это ситуация, когда одна транзакция повторно выполняет запрос, возвращающий множество строк, и видит новые строки, которые были добавлены другой транзакцией за время выполнения первой. Такие изменения могут влиять на результаты выборки, вызывая несогласованность данных.

📌 Пример:

- Транзакция A выполняет запрос: SELECT * FROM orders WHERE amount > 100;
- В это время транзакция B добавляет новую запись: INSERT INTO orders (id, amount) VALUES (10, 150); и фиксирует изменения (COMMIT).
- Транзакция A повторяет свой запрос: SELECT * FROM orders WHERE amount > 100;
- Теперь в результате запроса появляется новая запись с id = 10, которая не была видна в первой выборке.

Фантомные чтения возможны на уровнях изоляции ниже SERIALIZABLE. Уровень REPEATABLE READ защищает от dirty и non-repeatable reads, но не от фантомных. Только уровень SERIALIZABLE гарантирует полную консистентность, исключая фантомные чтения за счёт блокировки или иного способа предотвращения изменений в диапазонах данных.

❓ Что такое область видимости (scope) бина в Spring?

Область видимости в Spring определяет жизненный цикл и видимость бинов в контейнере IoC. Основные области видимости:

- Singleton (по умолчанию):
Один экземпляр бина создаётся на весь контекст Spring. Используется для общих объектов.

- Prototype:
Каждый запрос к контейнеру создаёт новый экземпляр бина.

- Request:
Бин создаётся для каждого HTTP-запроса (только в веб-приложениях).

- Session:
Один бин создаётся на одну HTTP-сессию.

- Application:
Один бин на весь жизненный цикл ServletContext.

- WebSocket:
Один бин на WebSocket-сессию.

Для указания области видимости используется аннотация @Scope.

🏢📊 Как сократить расходы на инфраструктуру в 20 раз: опыт внедрения мультитенантной архитектуры

Снизить затраты на инфраструктуру в десятки раз — не фантастика, а реальность. Мультитенантная архитектура помогает не только экономить деньги, но и упрощает подключение новых клиентов, масштабирование и обслуживание системы. Такой подход значительно облегчает работу и открывает новые возможности для роста.

Хотите узнать, как правильно её внедрить, избежать типичных ошибок и достичь впечатляющих результатов? Ознакомьтесь с реальным опытом, который вдохновит на изменения. 🍹

🔗 Читать статью
🔗 Зеркало

❓ Что такое optimistic и pessimistic locking?

🔹 Optimistic Locking использует версионный контроль. Каждый объект данных имеет поле версии (@Version в JPA), которое обновляется при изменении. При сохранении проверяется, что версия не изменилась. Если она изменилась (другая транзакция уже обновила объект), операция завершается с ошибкой. Это подход минимально блокирует ресурсы, но требует обработки конфликтов на уровне приложения.

🔹 Pessimistic Locking заключается в блокировке строк для предотвращения их изменения другими транзакциями. Существует три вида блокировок в JPA:

PESSIMISTIC_READ – другие транзакции могут читать, но не изменять данные.
PESSIMISTIC_WRITE – блокировка на запись, другие транзакции не могут читать и изменять данные.
PESSIMISTIC_FORCE_INCREMENT – аналогично WRITE, но увеличивает версию даже без изменений.

❗️ Когда использовать?

- Optimistic Locking подходит для систем с редкими конфликтами.
- Pessimistic Locking лучше использовать в сценариях с высокой конкуренцией или при необходимости строго гарантировать целостность данных.

💬 Обратная связь

По возможности вопросы выбираются с приближением к реальным собеседованиям или чему-то применимому в целом. А не вопросы вида "зачем мне это, что это вообще такое, никогда не задумывался об этом и не буду". Как вам кажется, удаётся это или нет?

Поставьте реакцию — каждый отзыв очень важен. Также можете в комментариях поделиться своим мнением, что можно улучшить. Сделаем контент интереснее вместе.

🔥 - Всё супер, админ красавчик
👍🏼 - Хорошо, большинство вопросов интересны/полезны
🤔 - Удовлетворительно, не все вопросы полезны/интересны
😢 - Что-то не нравится, напишу в комментариях, что именно

ℹ️ Что такое "Проблема бриллианта" (Diamond Problem)?

Проблема бриллианта (или Diamond Problem) — это ситуация, которая возникает в языках программирования с поддержкой множественного наследования. Она заключается в том, что если один класс наследует два или более класса, которые имеют общий предок, то возникает неопределенность, с какого родительского класса должны быть унаследованы члены (методы или поля).

В Java множественное наследование классов не поддерживается, но проблема все равно может возникнуть при использовании интерфейсов.

interface A {
    void method();
}

interface B extends A {
    @Override
    default void method() {
        System.out.println("Method from B");
    }
}

interface C extends A {
    @Override
    default void method() {
        System.out.println("Method from C");
    }
}

class D implements B, C { }

public class Main {
    public static void main(String[] args) {
        D d = new D();
        d.method();  // Какая версия метода будет вызвана?
    }
}

📌 В чем суть проблемы?

Когда класс D реализует оба интерфейса B и C, которые оба предоставляют дефолтные реализации метода method(), возникает неопределенность — какую версию метода должен использовать класс D? При компиляции будет выброшен error: class D inherits unrelated defaults for method() from types B and C.

Это решается с помощью явного переопределения метода в классе D, что позволяет избежать конфликтов.

class D implements B, C {
    @Override
    public void method() {
        B.super.method();
        // или можно использовать C.super.method(), если хотите вызвать метод из C
    }
}