Привет! В этой статье я бы хотел рассказать, как Spring'овая аннотация @Transactional ведет себя при возникновении исключений. Про это немало написано, в том числе на Хабре. Например, тут или тут. Поэтому, чтобы не повторяться, я не буду подробно расписывать как и почему исключения влияют на откат транзакций, а вместо этого просто покажу несколько примеров.

Если коротко, то Spring обрабатывает исключения в методах, помеченных @Transactional, следующим образом:

• RuntimeException'ы приводят к откату транзакции, checked exception'ы не приводят;

• RuntimeException'ы приводят к откату транзакции в момент, когда exception пересекает границы @Transactional-метода. Даже если вы перехватите это исключение выше по стеку, транзакция все равно откатится;

• Этим поведением можно управлять через атрибуты rollbackFor / noRollbackFor у аннотации @Transcational.

Пример 1

@Slf4j
@Component
public class Bean {
  private final BeanRepository repository;

  public Bean (BeanRepository repository) {
    this.repository = repository;
  }

  @Transactional
  public void saveItems(List<Item> items) {
    for(Item item: items) {
      try {
        saveItem(item);
      } catch(RuntimeException e) {
        log.error("Could not save item {}", item, e);
      }
    }
  }

  @Transactional
  public void saveItem(Item item) {
    if(item.foo().equals("BAD_ITEM")) 
      throw new RuntimeException();

    repository.save(item);
  }
}

Что будет, если мы передадим для сохранения список Item'ов, у которых 0-й и 2-й элемент НЕ являются BAD_ITEM'ами, а 1-й - является?

1. Ничего не будет сохранено, поскольку RuntimeException в методе saveItem откатит транзакцию;

2. Будет сохранен только 0-й элемент;

3. Будет сохранен 0-й и 2-й элемент.

Пример 2

@Component
public class Bean {
  private final BeanRepository repository;

  public Bean(BeanRepository repository) {
    this.repository = repository;
  }

  @Transactional
  public void saveItem(Item item) {
    if(item.foo().equals("BAD_ITEM")) 
      throw new RuntimeException();

    repository.save(item);
  }
}

@Slf4j
@Controller
public class Controller {
  private final Bean bean;

  public Controller(Bean bean) {
    this.bean = bean;
  }
  
  public void saveItems(List<Item> items) {
    for(Item item: items) {
      try {
        bean.saveItem(item);
      } catch(RuntimeException e) {
        log.error("Could not save item {}", item, e);
      }
    }
  }
}

Тот же вопрос: что будет, если мы передадим для сохранения список Item'ов, у которых 0-й и 2-й элемент НЕ являются BAD_ITEM'ами, а 1-й - является?

1. Ничего не будет сохранено;

2. Будет сохранен только 0-й элемент;

3. Будет сохранен 0-й и 2-й элемент.

Пример 3

Все то же самое, но теперь метод saveItems тоже @Transactional:

@Slf4j
@Controller
public class Controller {
  ...
  @Transactional
  public void saveItems(List<Item> items) {
    for(Item item: items) {
      try {
        bean.saveItem(item);
      } catch(RuntimeException e) {
        log.error("Could not save item {}", item, e);
      }
    }
  }
}

1. Ничего не будет сохранено;

2. Будет сохранен только 0-й элемент;

3. Будет сохранен 0-й и 2-й элемент.

Пример 4

А теперь добавим в контроллер ограничение, что RuntimeException'ы не должны откатываться.

@Slf4j
@Controller
public class Controller {
  ...
  @Transactional(noRollbackFor = RuntimeException.class)
  public void saveItems(List<Item> items) {
      try {
        bean.saveItem(item);
      } catch(RuntimeException e) {
        log.error("Could not save item {}", item, e);
      }
  }
}

1. Ничего не будет сохранено;

2. Будет сохранен только 0-й элемент;

3. Будет сохранен 0-й и 2-й элемент.

Пример 5

Перенесем noRollbackFor на saveItem. А у контроллера уберем код по перехватыванию RuntimeException.

@Component
public class Bean {
  private final BeanRepository repository;

  public Bean(BeanRepository repository) {
    this.repository = repository;
  }

  @Transactional(noRollbackFor = RuntimeException.class)
  public void saveItem(Item item) {
    if(item.foo().equals("BAD_ITEM")) 
      throw new RuntimeException();

    repository.save(item);
  }
}

@Slf4j
@Controller
public class Controller {
  private final Bean bean;

  public Controller(Bean bean) {
    this.bean = bean;
  }

  @Transactional  
  public void saveItems(List<Item> items) {
    for(Item item: items) {
      bean.saveItem(item);
    }
  }
}

1. Ничего не будет сохранено

2. Будет сохранен только 0-й элемент;

3. Будет сохранен 0-й и 2-й элемент.

Пример 6

Пометим оба @Transactional-метода так, чтобы они не откатывали runtime-исключения:

@Component
public class Bean {
  private final BeanRepository repository;

  public Bean(BeanRepository repository) {
    this.repository = repository;
  }

  @Transactional(noRollbackFor = RuntimeException.class)
  public void saveItem(Item item) {
    if(item.foo().equals("BAD_ITEM")) 
      throw new RuntimeException();

    repository.save(item);
  }
}

@Slf4j
@Controller
public class Controller {
  private final Bean bean;

  public Controller(Bean bean) {
    this.bean = bean;
  }

  @Transactional(noRollbackFor = RuntimeException.class)
  public void saveItems(List<Item> items) {
    for(Item item: items) {
      bean.saveItem(item);
    }
  }
}

1. Ничего не будет сохранено

2. Будет сохранен только 0-й элемент;

3. Будет сохранен 0-й и 2-й элемент.

Пример 7

У Spring Data в интерфейсе CrudRepository есть такой вот метод:

void deleteAllById(Iterable<? extends ID> ids)

Что если ему на вход передать среди существующих идентификаторов один несуществующий? Я бы ожидал, что он удалит те, что есть, и проигнорирует те, которых нет (ну, как и обычный оператор delete в SQL). И да, Spring Data, именно так и сделает, но только если вы используете Spring Data 3. А ему на данный момент что-то около полугода. Если вы используете более раннюю версию, вы получите ошибку EmptyResultDataAccessException (Spring Data писали странные люди, и да, пошла она к черту эта ваша обратная совместимость).

@Component
public class Bean {
  private final BeanRepository repository;

  public Bean(BeanRepository repository) {
    this.repository = repository;
  }

  @Transactional(noRollbackFor = EmptyResultDataAccessException.class)
  public void deleteItems(List<Item> items) {
    repostory.deleteAllById(items.stream().map(Item::id).toList());
  }
}

Что будет, если в середине списка несуществующий айдишник в Spring Data 2.x?

Пример 8

public interface BeanRepository extends JpaRepository<Item, Long> { 
  @Override
  @Transactional(noRollbackForClassName = "org.springframework.dao.EmptyResultDataAccessException", rollbackFor = DataAccessException.class, noRollbackFor = RuntimeException.class)
  void deleteAllById(Iterable<? extends Long> longs);
}

Что будет если какого-то из айдишников нет?

Итоги

1. Атрибуты rollbackFor / noRollbackFor управляют только поведением транзакции в случае возникновения исключений. Сами исключения по-прежнему пробрасываются выше по стеку;

2. Атрибуты rollbackFor / noRollbackFor не наследуются @Transactional-методами ниже по стеку вызовов, даже если используется Propagation.REQUIRED;

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