В чем разница между созданием клиента и заказа в одной и двух разных транзакциях?

Одна транзакция vs две транзакции при создании клиента и заказа

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

Сценарий: создание клиента и его первого заказа

Вариант 1: Одна транзакция

@Transactional
public Order createCustomerWithOrder(CustomerRequest request) {
    // ВСЁ в одной транзакции
    Customer customer = new Customer(request.getName());
    customerRepository.save(customer);
    
    Order order = new Order(customer, request.getOrderItems());
    order.setTotal(calculateTotal(order));
    orderRepository.save(order);
    
    // Либо всё успешно, либо откатывается всё
    return order;
}

Что происходит:

BEGIN TRANSACTION
  INSERT INTO customers (name) VALUES ('John')
  INSERT INTO orders (customer_id, total) VALUES (123, 99.99)
COMMIT

Гарантии:

• Либо оба успешны, либо оба откатываются
• Атомарность: нет половинчатого состояния

Вариант 2: Две разные транзакции

public Order createCustomerWithOrder(CustomerRequest request) {
    // Первая транзакция
    Customer customer = createCustomer(request);
    
    // Вторая транзакция (отдельная!)
    Order order = createOrder(customer, request);
    
    return order;
}

@Transactional
private Customer createCustomer(CustomerRequest request) {
    return customerRepository.save(new Customer(request.getName()));
    // COMMIT здесь
}

@Transactional
private Order createOrder(Customer customer, CustomerRequest request) {
    // BEGIN new transaction
    Order order = new Order(customer, request.getOrderItems());
    return orderRepository.save(order);
    // COMMIT здесь
}

Что происходит:

BEGIN TRANSACTION 1
  INSERT INTO customers (name) VALUES ('John')
COMMIT  ← Клиент уже сохранён!

BEGIN TRANSACTION 2
  INSERT INTO orders (customer_id, total) VALUES (123, 99.99)
COMMIT  ← Заказ сохранён

Разница в критических аспектах

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

Одна транзакция:

@Transactional
public Order createBoth(CustomerRequest request) {
    Customer customer = customerRepository.save(new Customer(request.getName()));
    
    // ОШИБКА ЗДЕСЬ!
    Order order = createOrderWithValidation(customer); // может выбросить исключение
    // ↓
    // Если выброшена ошибка → откатываются ОБА insert'а
}

// Результат БД: нет ни клиента, ни заказа ✅

Две транзакции:

public Order createBoth(CustomerRequest request) {
    Customer customer = createCustomer(request);  // COMMIT
    // ← Клиент уже в БД!
    
    Order order = createOrderWithValidation(customer);  // ❌ ОШИБКА!
    // Исключение выброшено
    // ↓
    // Откатывается только вторая транзакция
}

// Результат БД: есть клиент, но нет заказа ❌
// Данные в несогласованном состоянии!

2. Обработка ошибок

// ОДНА ТРАНЗАКЦИЯ - безопасно
@Transactional
public Order createBoth(CustomerRequest request) {
    try {
        Customer customer = customerRepository.save(new Customer(request.getName()));
        Order order = orderRepository.save(new Order(customer, ...));
        return order;
    } catch (Exception e) {
        // Вся транзакция откатывается автоматически
        // Состояние БД остаётся согласованным
        throw new OrderCreationException("Failed to create", e);
    }
}

// ДВЕ ТРАНЗАКЦИИ - небезопасно
public Order createBoth(CustomerRequest request) {
    Customer customer = createCustomer(request);  // Committed
    
    try {
        Order order = createOrder(customer, request);
        return order;
    } catch (Exception e) {
        // Клиент уже в БД, заказ не создан
        // Нужна компенсирующая транзакция!
        deleteCustomer(customer.getId());
        throw new OrderCreationException("Failed to create order", e);
    }
}

3. Производительность

Одна транзакция:

Одна блокировка на весь процесс
Время: вставка клиента + вставка заказа + 1 commit

Две транзакции:

Два отдельных commit'а
Время: вставка клиента + commit1 + вставка заказа + commit2
Зато меньше блокировок друг на друга

4. Видимость данных для других транзакций

Одна транзакция:

@Transactional
public Order createBoth(CustomerRequest request) {
    Customer customer = customerRepository.save(new Customer(request.getName()));
    // ← Другие транзакции НЕ видят клиента ещё!
    
    Order order = orderRepository.save(new Order(customer, ...));
    return order;
    // ← commit выполняется здесь, только теперь видны оба
}

Две транзакции:

public Order createBoth(CustomerRequest request) {
    Customer customer = createCustomer(request);  // commit
    // ← Другие транзакции ВИДЯТ клиента!
    // ← Если здесь падает сервер, заказ не создан
    
    Order order = createOrder(customer, request);
    return order;
}

Практические примеры последствий

Сценарий 1: Сбой при валидации заказа

// ОДНА ТРАНЗАКЦИЯ
@Transactional
public Order create(Request req) {
    Customer c = save(new Customer(...));  
    Order o = new Order(c, ...);          
    validate(o);  // ← выброшена исключение!
    save(o);      // ← не выполнится
    return o;
}
// БД: нет ни клиента, ни заказа ✅ Согласовано

// ДВЕ ТРАНЗАКЦИИ
public Order create(Request req) {
    Customer c = createCustomer(...);      // COMMIT
    Order o = new Order(c, ...);          
    validate(o);  // ← выброшена исключение!
    save(o);      // ← не выполнится
    return o;
}
// БД: есть клиент, нет заказа ❌ Несогласовано

Сценарий 2: Проверка уникальности

// ОДНА ТРАНЗАКЦИЯ - безопасна
@Transactional
public Order create(Request req) {
    Customer customer = save(new Customer(email));  // Может выбросить уникальное нарушение
    Order order = save(new Order(customer, ...));
    return order;
}
// Если email не уникален → откатывается всё ✅

Рекомендации для разных сценариев

Используй ОДНУ транзакцию когда:

// Простые операции, которые должны быть атомарными
@Transactional
public Order checkout(Cart cart) {
    Customer customer = getOrCreateCustomer(cart.getCustomerId());
    Order order = createOrderFromCart(cart);
    updateInventory(cart.getItems());
    return order;
    // Либо все успешны, либо ничего
}

Используй ДВЕ транзакции когда:

// Когда нужна высокая параллельность
public Order process(Request req) {
    // Фаза 1: быстрая
    Customer c = createCustomerQuickly(req);  // commit
    
    // Фаза 2: может быть долгой (интеграция, API)  
    Order o = createOrderWithExternalAPI(c);  // отдельная транзакция
    
    // ДА, есть риск несогласованности, но параллельность выше
}

// Когда нужны разные уровни изоляции
@Transactional(isolation = Isolation.READ_UNCOMMITTED)
public void step1() { /* ... */ }

@Transactional(isolation = Isolation.SERIALIZABLE)
public void step2() { /* ... */ }

Таблица сравнения

Заключение

По умолчанию используй одну транзакцию (@Transactional на уровне usecase/service). Это гарантирует консистентность.

Дели на две транзакции только если:

1. Явно нужна высокая параллельность
2. Реализуешь Saga pattern для распределённых транзакций
3. Понимаешь риски и готов к компенсирующим транзакциям

Невыполненный Sagas паттерн с двумя транзакциями — частая причина потери данных.