Что произойдет если одним методом поменять что-то в БД?

Изменение БД в одном методе: последствия и контроль

Этот вопрос касается того, что происходит, когда один метод изменяет данные в базе данных. Ответ зависит от контекста транзакции и архитектуры приложения.

Сценарий 1: Метод без явной транзакции

public class UserService {
    private UserRepository userRepository;
    
    // ❌ Проблема: без @Transactional
    public void updateUser(int id, String newName) {
        User user = userRepository.findById(id);
        user.setName(newName);
        // Что произойдет?
    }
}

Что произойдет:

1. Автокоммит (auto-commit) активирован — изменения сразу коммитятся в БД
2. Если другой код захочет отменить это изменение — будет слишком поздно
3. Нет откатки (rollback) при ошибке
4. Если возникла исключение после изменения — данные уже в БД

public void updateUser(int id, String newName) {
    User user = userRepository.findById(id);  // SELECT
    user.setName(newName);
    userRepository.save(user);  // UPDATE (auto-commit)
    
    // Если вот здесь выбросится исключение
    int result = 1 / 0;  // ArithmeticException
    
    // ❌ Данные УЖЕ изменены в БД!
    // ❌ Откатить нельзя
}

Сценарий 2: Метод с @Transactional (Spring)

public class UserService {
    private UserRepository userRepository;
    
    @Transactional  // ✓ Правильно!
    public void updateUser(int id, String newName) {
        User user = userRepository.findById(id);
        user.setName(newName);
        // userRepository.save() не нужен, Hibernate отслеживает изменения
    }
}

Что произойдет:

1. Транзакция открывается при входе в метод
2. Все изменения отслеживаются (в памяти Hibernate)
3. При нормальном выходе — auto-commit (COMMIT)
4. При исключении — автоматический rollback (ROLLBACK)
5. Все или ничего — либо все изменения сохранены, либо ни одно

@Transactional
public void updateUser(int id, String newName) {
    User user = userRepository.findById(id);
    user.setName(newName);
    
    // Если здесь ошибка
    int result = 1 / 0;  // ArithmeticException
    
    // ✓ Spring ОТКАТИТ изменение (rollback)
    // ✓ В БД не будет изменений
}

Архитектурные последствия

1. Консистентность данных

// Пример: перевод денег со счета на счет
@Transactional
public void transferMoney(int fromAccount, int toAccount, BigDecimal amount) {
    Account from = accountRepository.findById(fromAccount);
    Account to = accountRepository.findById(toAccount);
    
    from.withdraw(amount);
    to.deposit(amount);
    
    // ✓ Если была ошибка после withdraw() — все откатится
    // ✓ Никогда не будет ситуации, когда деньги ушли, но не пришли
}

// Без @Transactional ❌
// Если ошибка между withdraw и deposit:
// - Деньги уйдут со счета from
// - Не попадут на счет to
// - Потеря денег!

2. Изоляция от других транзакций

// Транзакция A
@Transactional(isolation = Isolation.READ_COMMITTED)
public void updatePrice(int productId, BigDecimal newPrice) {
    Product product = productRepository.findById(productId);
    product.setPrice(newPrice);
    
    // Пока транзакция А не закончилась:
    // - Транзакция B может видеть старую цену (READ_COMMITTED)
    // - Или новую цену (зависит от уровня изоляции)
}

3. Видимость изменений

@Transactional
public void updateAndQuery() {
    User user = userRepository.findById(1);  // SELECT
    user.setName("New Name");
    
    // В пределах этой транзакции видно новое значение
    System.out.println(user.getName());  // "New Name"
    
    // Но в БД еще не изменено (до конца транзакции)
}

// Другая транзакция в этот момент
public void readUser() {
    User user = userRepository.findById(1);
    System.out.println(user.getName());  // "Old Name" (старое значение)
}

Несколько методов в одной транзакции

public class OrderService {
    @Transactional  // Одна транзакция для всех методов
    public void placeOrder(Order order) {
        validateOrder(order);        // Проверка
        saveOrder(order);            // INSERT в orders
        reduceInventory(order);      // UPDATE inventory
        sendNotification(order);     // Может быть async
    }
    
    private void saveOrder(Order order) {
        // В той же транзакции
        orderRepository.save(order);
    }
    
    private void reduceInventory(Order order) {
        // В той же транзакции
        for (Item item : order.getItems()) {
            Inventory inv = inventoryRepository.findById(item.getProductId());
            inv.decreaseStock(item.getQuantity());
        }
    }
}

// Если reduceInventory выбросит исключение:
// ✓ Даже saveOrder откатится
// ✓ Заказ не будет создан
// ✓ Инвентарь не будет уменьшен

Потенциальные проблемы

1. Deadlock

@Transactional
public void method1() {
    // Блокировка таблицы A
    Table1 t1 = repository1.findById(1);
    Thread.sleep(100);  // Можно привести к deadlock
    // Блокировка таблицы B
    Table2 t2 = repository2.findById(1);
}

// Другая транзакция
@Transactional
public void method2() {
    // Блокировка таблицы B в обратном порядке
    Table2 t2 = repository2.findById(1);
    // Блокировка таблицы A
    Table1 t1 = repository1.findById(1);
}

// ❌ Может произойти deadlock!

2. Долгая транзакция

@Transactional
public void processOrder() {
    Order order = orderRepository.findById(1);
    // Дорогая операция - обрабатываем платеж
    paymentGateway.processPayment(order);  // 10 сек
    // Затем сохраняем
    order.setStatus("PAID");
}

// ❌ Проблема: транзакция открыта 10 секунд
// ❌ Блокирует другие транзакции
// ❌ Может привести к timeout

Решение: вынести внешний call за пределы транзакции

public void processOrder() {
    Order order = orderRepository.findById(1);
    
    // Вне транзакции
    paymentGateway.processPayment(order);  // 10 сек
    
    // Короткая транзакция
    updateOrderStatus(order);
}

@Transactional
private void updateOrderStatus(Order order) {
    order.setStatus("PAID");
}

Уровни логирования изменений

@Transactional
public void updateUser(int id, String newName) {
    User user = userRepository.findById(id);
    String oldName = user.getName();
    user.setName(newName);
    
    // Логировать изменение
    auditLog.log("User " + id + " name changed from " + oldName + " to " + newName);
}

// Или использовать Spring Data Envers для аудита
@Entity
@Audited
public class User {
    private String name;
}

// Будет автоматически создана история всех изменений

Откатка при ошибке

@Transactional
public void riskyOperation() {
    userRepository.save(new User("Alice"));
    
    // При исключении — все откатится
    validateUser(null);  // Может выбросить исключение
}

// Spring перехватит исключение и сделает rollback
// Пользователь Alice не будет сохранена в БД

// Но можно обработать исключение:
@Transactional
public void riskyOperationWithHandling() {
    userRepository.save(new User("Alice"));
    
    try {
        validateUser(null);
    } catch (ValidationException e) {
        // Если мы сами обработали исключение
        // Spring ВСЁ РАВНО сделает rollback (по умолчанию)
        
        // Чтобы закоммитить несмотря на исключение:
        // @Transactional(noRollbackFor = ValidationException.class)
    }
}

Best Practices

public class BestPractices {
    /*
    1. Используй @Transactional для операций изменения БД
    
    2. Держи транзакции короткими
       ❌ Плохо: @Transactional с сетевыми запросами
       ✓ Хорошо: только операции БД в транзакции
    
    3. Избегай вложенных транзакций (если не нужны)
    
    4. Используй read-only для чтения
       @Transactional(readOnly = true)
    
    5. Явно указывай isolation уровень, если нужно
    
    6. Логируй изменения (Envers, Hibernate Auditing)
    
    7. Тестируй откатку при ошибках
    */
}

Итог

Если один метод изменяет БД:

Без @Transactional:

• Изменения сразу коммитятся (auto-commit)
• Нет откатки при ошибке
• Риск несоответствия данных

С @Transactional:

• Все изменения в памяти
• При ошибке — автоматический rollback
• Гарантия: "все или ничего"
• Полная безопасность и консистентность

Рекомендация: ВСЕГДА используй @Transactional для операций изменения БД в Java приложениях.