IMHO Не допускать таких ситуаций на проде.

Не хранить state в пакетах (глобальные переменные) или корректно проводить накат update'ов/upgrade'ов (не допускать invalid package и перекомпилировать в момент update'а/upgrade'а)

Обработка ora-4068, понятно, заключается в повторе вызвавшей сбой операции.


Совершенно не понятно.

Например последовательность вызовов:

CSC_CONTEXT_PKG.Initialize( p_object => some_id );
CSC_PROCESS_PKG.Calculate;

может вызвать ORA-6508, ORA-04068 на второй операции, а повторять скорее всего нужно все. Т.к. "state of packages" могли стать уже не корректные, а устанавливаются именно в первой операции.

Наши джависты вменяемого решения предложить отчего-то не в состоянии - предлагают чуть ли не все вызовы в проекте catch-ами обвешивать.

Или реализовать свой helper класс / ф-цию / процедуру (например свой Statement/CallableStatement) и всюду использовать его вместо стандартного.

Ну или вообще сделать свой JDBC драйвер с нужным поведением.

Сделать можно все, вопрос насколько проблема сильно стоит (сколько денег на решение готовы потратить).

IMHO

Ну и вообще-то, если залезть в доку MyBatis тут же находится:

https://mybatis.org/mybatis-3/java-api.html

ДокаSqlSessionFactory
SqlSessionFactory has six methods that are used to create SqlSession instances. In general, the decisions you'll be making when selecting one of these methods are:

Transaction: Do you want to use a transaction scope for the session, or use auto-commit (usually means no transaction with most databases and/or JDBC drivers)?
Connection: Do you want MyBatis to acquire a Connection from the configured DataSource for you, or do you want to provide your own?
Execution : Do you want MyBatis to reuse PreparedStatements and/or batch updates (including inserts and deletes)?


ДокаStatement Execution Methods
These methods are used to execute SELECT, INSERT, UPDATE and DELETE statements that are defined in your SQL Mapping XML files. They are pretty self explanatory, each takes the ID of the statement and the Parameter Object, which can be a primitive (auto-boxed or wrapper), a JavaBean, a POJO or a Map.

<T> T selectOne(String statement, Object parameter)
<E> List<E> selectList(String statement, Object parameter)
<T> Cursor<T> selectCursor(String statement, Object parameter)
<K,V> Map<K,V> selectMap(String statement, Object parameter, String mapKey)
int insert(String statement, Object parameter)
int update(String statement, Object parameter)
int delete(String statement, Object parameter)


Хотя не знаю, что проще/универсальнее переопределить. JDBC или MyBatis классы.

Если я правильно понимаю доку, класс для SqlSessionFactory должен задаваться в конфигах. Делаете свою реализацию.

Дальше переопределяете/наследуете SqlSession, переопределяете 7 методов для выполнения SQL команд.

с MyBatis не работал. Сужу по доке и общей логике "паттерна Factory" )))

Я вообще очень редко вижу ora-4068. Обычно ситуации invalid state of package у меня приводят к 6508.

Если при накате патчей в базе никого не было (после патча все переподключились) и не было invalid package, то ora-4068 IMHO взятся не откуда.

А результат работы и переповторов в процессе наката - все равно не предсказуемо.

Нет.

При обновлении пакета сбрасываются переменные определенные в этом пакете (что логично). Соответственно при первом вызове данного пакета в уже существующей сессии, система сообщает, что состояние (переменные) пакета стали некорректны.

Логично, что после обновления части софта (базы), желательно софт перезапустить или как минимум переконектится. Но как я понимаю, у топик стартера проблема еще осложняется пуллом коннектов.

Мне кажется, что в системах 24x7 должен быть прописан/продуман регламент обновлений и, соответственно, действий после наката обновлений. Решать можно по разному. Подход топик стартера (тупо повторять запросы), костыльный, но вполне вероятно что в его ситуации и работающий.

В "общем" он не работает или, как минимум, может работать не корректно. Т.к. повтор SQL команды, не является корректным повтором бизнес операции (бизнес операция может содержать много SQL команд обращающихся ко многим пакетам).

IMHO

Можно ссылку на доку с разделением exception на error и warning? )))
Мне кажется, это какой-то вновь придуманный термин. Такое изобретение видел только в Oracle CC&B и жутко на него плевался (т.к. IMHO это бред, прикладные warning'и обрабатывать через exception).

В данном случае, это вполне нормальная ошибка. Состояние пакетов поменялось, результат работы (в общем случае) непредсказуем.

Если проблема из-за пула коннектов, то наверное проблема в некоректной инициализации коннекта после получения из пула. Почти все пулы, могут настраивать SQL команду, которую нужно дернуть при получении/проверки коннекта на валидность.

Наверное можно делать PL/SQL ф-цию Init, которая дернет все пакеты с состояними (переменными) и обнулят данные состояния (переменные), что бы данные между соединениями не утекали (что плохо и с точки зрения секьюрети) в соседние сессии.

В общем, мне все же кажется, что проблема не только в коде, но и логическая / организационная. В общем, прежде чем кодировать, "подумать надо" ( C )

IMHO

p.s. на одной из пред. работ, программисту прилетел официальный выговор от директора, из-за того, что он написал консультанту/архитектору, что перед тем как делать задачу, хорошо бы "подумать". Выговор был, что архитектор знает свою должностную инструкцию и что ему делать. На что пришли к выводу, что в должностной инструкции на позицию архитектора, пункт "думать" забыли прописать или явно написали "на работе думать запрещается" )))

Совершенно нормальный серверный код.

Пример выше привел. Сначала выполняем инициализацию, потом какие-то действия (возможно много и долго) где данные (состояние) установленные этой инициализацией используются. Бизнес операция одна - SQL команд много. Ошибка может возникнуть на любой SQL команде.

Правильный повтор - откатить и повторить всю бизнес операцию . Повтор ОДНОЙ SQL команды, в общем случае, является не корректным. В большинстве систем, которые я видел и где использовалось состояние пакектов, бизнес операция очень редко бывает только одной SQL командной. Ради того, что бы передавать данные между разными SQL командами пакетные переменные (состояние) и используют. IMHO & AFAIK

Если у Вас бизнес операция == одна команда (процедура, анонимный блок). То повтор наверное будет корректным решением.

IMHO

Консультанты не являлись вышестоящими руководителями. Т.ч. пошли нафиг.

Мало того, общепризнанный (начальством) умственный уровень "среднего" консультанта, общепризнанно был меньше, того же среднего уровня программистов. Т.к. огромная часть консультантов неделю назад институт закончила.

Но если у Вас на задачу в Jira "убиться ап стенку", "выпрыгнуть из окна", все программисты дружно начинают ее выполнять - можно только поздравить, отдел HR работает качественно ))))

Например в Oracle DBMS_SESSION есть DBMS_SESSION.RESET_PACKAGE

https://oracle-base.com/articles/misc/dbms_session#packages

Sessions have the ability to alter package state by amending the values of package variables. If a session is being used as part of a connection pool and the state of its packages are not reinitialized, this can lead to unexpected behavior . To solve this, the RESET_PACKAGE procedure, available since Oracle 7, can be called to reinitialize all packages.

Нет. Когда приложение желает получить чужую DB-сессию из пула, оно должно обнулить состояние - что логично.

Например DBMS_SESSION.RESET_PACKAGE

Большинство пулов соединений, которые видел, в настройках позволяли указывать код для инициализации сессии (при получении из пула) и код для проверки валидности сессии (она могла быть закрыта со стороны сервера).

Сам с такой проблемой не сталкивался. Т.ч. DBMS_SESSION.RESET_PACKAGE не использовал.