Андрей, вы в том топике дали профессиональный ответ, я вас отблагодарил, а здесь вы по какой-то причине всеми силами пытаетесь увернуться от точно такого же профессионального ответа. Конкретно в этом форуме у участников кругозор несколько шире, ввиду того что постоянно приходится работать с разными системами, поэтому юродствуете вы совершенно зря. Вот давайте разберем ситуацию с ошибкой более подробно: вы разрабатываете (или поддерживаете, не суть важно) некую систему, где было принято решение бизнес-логику зашить в хранимые процедуры (насколько это решение правильное и какие были мотивы мы не обсуждаем), т.е. вы (БД) клиенту (жава-приложению) помимо (или вместо) стандартных CRUD-операций предоставляете еще другой API в виде неких RPC-вызовов к БД, в какой-то момент времени происходит осознание того, что обновление реализации предоставляемого API для клиента происходит не так прозрачно как хотелось бы, вы идете к вендору (ораклу) и узнаете, что существует потенциальная возможность избежать проблем, однако стоимость "правильного решения" слишком высока (трудозатраты, злой заказчик, который хочет вчера, возможно стоимость лицензий и пр.), ну и в итоге вы оказываетесь на этом форуме с вопросом какбы в жаве побыстрому нагородить костылей...

Вот есть ошибка:


что она по своей сути означает? Означает она следующее: реализация API, предоставляемого клиенту, поменялась и вероятнее всего, если повторно выполнить RPC то ошибки уже не будет, но вот вопрос: а насколько валидны вычисления, сделанные в текущей транзакции до возникновения этой ошибки? И здесь беда в том, что никто не знает, т.е.:
- БД при обновлении хранимых процедур просто пометила, что у них реализация поменялась, и выкидывает ошибку
- драйвер БД не уполномочен принимать решение о повторе RPC и поэтому делегирует решение клиенту (жава-приложению)

и по хорошему здесь следует откатить транзакцию и повторить все вычисления заново (это ровно то, что все остальные фреймворки и делают, видимо за исключением MyBatis), однако тут возникаете вы с крамольной идеей, что можно перехватить вызов конкретного RPC и в случае довольно общей ошибки повторить, ну извините, раз этот RPC ваш и обладает свойством идемпотентности, а жава-приложение уже успело получить соединение, то и реализуйте повтор операций у себя, а не тащите его на клиента, т.е. не стоит размазывать крайне сомнительные решения по всему проекту - держите их в одном месте.


Теперь давайте разберем то, чем вы гордитесь...




- во-первых, два с половиной часа для более-менее серьезной системы - это как-то мало, я бы только недели 2 писал бы интеграционные тесты
- во-вторых, утверждение сделанное в приведенном коде примерно звучит так (здесь я понимаю что у вас с пониманием написанного возникают определенные затруднения): если второе исключение в цепочке исключений является исключением, связанным с обращением к БД, и в тексте этого исключения есть "ORA-04068", то повторить RPC. Проблема здесь в том, что подобный подход к решению проблемы разваливается при малейших изменениях как со стороны жава-кода, так и со стороны изменений в хранимых процедурах, например завтра в MyBatis решили добавить логирование вызовов, и исключение стало в цепочке уже не вторым, а третьим, или поменяли вы код на PL/SQL и ORA-04068 стало прилетать не от проблемной процедуры, а от совсем другой, или самой первой ошибкой была не ORA-04068, а какая-то другая.

Вообщем код на самом деле так себе, а учитывая вот это:


Я как-то удивлен, что для PL/SQL у вас ревью кода есть, а для жавы - нет.