Приходилось ли работать с голыми JDBC, писать вручную открытие сессии, коммит и rollback

Что проверяют

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

Как отвечать

Опишите последовательность своими словами: соединение берётся из пула, автокоммит выключается, запросы идут через PreparedStatement, в конце коммит, в обработчике исключения откат, затем ресурсы закрываются и режим автокоммита возвращается на место.

conn.setAutoCommit(false);
try (PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setString(1, name);
    ps.executeUpdate();
    conn.commit();
} catch (SQLException e) {
    conn.rollback();
    throw e;
}

Добавьте то, что выдаёт опыт: конструкция try-with-resources закрывает ресурсы в обратном порядке, но откат за вас не делает, поэтому rollback пишется руками. Пакетная вставка через addBatch и executeBatch вместо запроса на строку. Точка сохранения, когда откатить нужно лишь часть работы. Уровень изоляции задаётся на соединении и влияет на блокировки. Для большой выборки помогает setFetchSize, иначе результат приедет в память целиком.

Где спотыкаются

Глотают исключение. Откат сделан, но наверх ничего не проброшено: вызывающий код считает операцию успешной, а данных нет. Логировать мало, ошибку нужно пробросить или превратить в доменную.

Возвращают в пул испорченное соединение. Если автокоммит остался выключенным, а транзакция незакрытой, следующий владелец получит чужой контекст и висящие блокировки. Восстановление режима делается в блоке finally.

Собирают запрос конкатенацией строк. Это классическая инъекция, а заодно потеря кэша планов на стороне базы. Параметры всегда подставляются через PreparedStatement, включая те, что кажутся безопасными числами.