Что делать при завершении ошибкой вложенной транзакции, если при вложенной транзакции внешняя приостанавливается

Управление вложенными транзакциями при ошибках

Вложенные транзакции (nested transactions, savepoints) — это важный механизм для управления состоянием БД при возникновении ошибок в подтранзакциях. Вопрос касается сценария, когда вложенная транзакция завершается с ошибкой, а внешняя транзакция приостанавливается (в состояние rollback-only). Это критический момент, требующий понимания транзакционной семантики.

Природа проблемы

В большинстве БД и ORM фреймворков (особенно в Spring + Hibernate) есть такое поведение:

1. Вложенная транзакция (savepoint) выбрасывает исключение
2. Внешняя транзакция переходит в состояние "rollback-only" — это означает, что её нельзя закоммитить, только откатить
3. Остальной код во внешней транзакции не может выполняться нормально

Это поведение защищает от логических ошибок в данных, но требует правильной обработки.

Решение 1: Использование REQUIRES_NEW

Это РЕКОМЕНДУЕМЫЙ подход. Вложенная операция выполняется в ОТДЕЛЬНОЙ, независимой транзакции:

@Service
public class OrderService {
    
    @Transactional
    public void processOrder(Order order) {
        saveOrder(order);
        
        try {
            sendNotification(order);
        } catch (Exception e) {
            logger.error("Notification failed", e);
        }
        
        updateInventory(order);
    }
    
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void sendNotification(Order order) {
        notificationService.send(order);
    }
}

Преимущества:

• Вложенная операция независима
• Ошибка в вложенной не пломбирует внешнюю
• Внешняя может продолжить работу

Решение 2: Явная обработка Savepoint

Используй TransactionTemplate и явное управление savepoints:

@Service
public class PaymentService {
    
    @Autowired
    private PlatformTransactionManager transactionManager;
    
    @Transactional
    public void processPayment(Payment payment) {
        savePayment(payment);
        
        DefaultTransactionDefinition def = new DefaultTransactionDefinition();
        TransactionStatus nested = transactionManager.getTransaction(def);
        
        try {
            processRefund(payment);
            transactionManager.commit(nested);
        } catch (Exception e) {
            logger.error("Refund failed", e);
            transactionManager.rollback(nested);
        }
        
        notifyAdmin(payment);
    }
}

Решение 3: Использование Nested propagation

@Service
public class BatchService {
    
    @Autowired
    private PlatformTransactionManager transactionManager;
    
    @Transactional
    public void processBatch(List<Item> items) {
        int successCount = 0;
        int failureCount = 0;
        
        for (Item item : items) {
            DefaultTransactionDefinition def = new DefaultTransactionDefinition();
            def.setPropagationBehavior(TransactionDefinition.PROPAGATION_NESTED);
            
            TransactionStatus nested = transactionManager.getTransaction(def);
            
            try {
                processItem(item);
                transactionManager.commit(nested);
                successCount++;
            } catch (Exception e) {
                logger.warn("Item failed: " + item.getId(), e);
                transactionManager.rollback(nested);
                failureCount++;
            }
        }
        
        logger.info("Batch completed: success=" + successCount + ", failures=" + failureCount);
    }
}

Решение 4: Перехват исключений на уровне сервиса

@Service
public class OrderProcessingService {
    
    @Transactional
    public void completeOrder(Order order) {
        createOrder(order);
        
        if (!tryApplyDiscount(order)) {
            logger.warn("Discount failed, continuing without it");
        }
        
        notifyWarehouse(order);
    }
    
    private boolean tryApplyDiscount(Order order) {
        try {
            discountService.apply(order);
            return true;
        } catch (DiscountException e) {
            logger.error("Discount error", e);
            return false;
        }
    }
}

Решение 5: Использование noRollbackFor

Если знаешь типы исключений, которые НЕ должны откатывать:

@Service
public class DataService {
    
    @Transactional(noRollbackFor = {TemporaryException.class})
    public void saveData(Data data) {
        data.save();
        
        try {
            callExternalService();
        } catch (TemporaryException e) {
            logger.warn("External service error", e);
        }
    }
}

Что НЕЛЬЗЯ делать

@Transactional
public void badApproach(Order order) {
    try {
        nestedOperation();
    } catch (Exception e) {
        order.save();  // ОШИБКА: не получится сейвнуть
    }
}

Это не сработает, потому что транзакция уже в rollback-only состоянии.

Сравнение подходов

REQUIRES_NEW — для независимых операций (уведомления, логирование). Полная независимость, но overhead.

NESTED — для контролируемого отката части операций. Один контекст БД, более эффективно, но сложнее.

Перехват исключений — для простых ошибок. Просто, но ограничено.

noRollbackFor — для известных типов ошибок. Элегантно, нужно предусмотреть.

Ключевые рекомендации

1. Используй REQUIRES_NEW по умолчанию для вложенных операций
2. Явно ловись исключения, если операция опциональна
3. Не полагайся на автоматическое восстановление — всегда контролируй состояние
4. Логируй неудачи вложенных операций для отладки
5. Документируй поведение для команды

Вывод

При ошибке вложенной транзакции нужно правильно выбрать уровень распространения транзакции (propagation). Рекомендуется использовать REQUIRES_NEW для независимых операций, NESTED для контролируемого отката, или явный перехват исключений перед выходом из внешней транзакции. Это показывает глубокое понимание Spring транзакций и ACID свойств.