Если покривели пакеты, типы - то в апексе получаю ошибку - об этом.
После перекомпиляции всех кривых объектов - ошибка все равно не исчезает! Приходится рестартовать приложение apex-listener.

в OHS такого не наблюдалось. Как перешли на Oracle REST Data Service - началась такая трабла на технологическом сервере, на котором и ведется разработка.

я так понимаю, должен происходить reset_package_state?

Oracle REST Data Service использует свой JDBC пул. В полу glassfish я такой проблемы тоже не замечал.
Думаю не хватает какой-то настройки...
-------
GlassFish Server Open Source Edition 4.0 (build 89)
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

------
Конфиг:

автор<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE properties SYSTEM " http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Wed Jun 18 13:03:47 GMT+06:00 2014</comment>
<entry key="cache.caching">false</entry>
<entry key="cache.directory">/tmp/apex/cache</entry>
<entry key="cache.duration">days</entry>
<entry key="cache.expiration">7</entry>
<entry key="cache.maxEntries">500</entry>
<entry key="cache.monitorInterval">60</entry>
<entry key="cache.procedureNameList"/>
<entry key="cache.type">lru</entry>
<entry key="db.hostname">host</entry>
<entry key="db.password">@pass</entry>
<entry key="db.sid">sid</entry>
<entry key="db.port">1521</entry>
<entry key="db.username">APEX_PUBLIC_USER</entry>
<entry key="debug.debugger">false</entry>
<entry key="debug.printDebugToScreen">false</entry>
<entry key="error.keepErrorMessages">true</entry>
<entry key="error.maxEntries">50</entry>
<entry key="jdbc.DriverType">thin</entry>
<entry key="jdbc.InactivityTimeout">1800</entry>
<entry key="jdbc.InitialLimit">3</entry>
<entry key="jdbc.MaxConnectionReuseCount">1000</entry>
<entry key="jdbc.MaxLimit">10</entry>
<entry key="jdbc.MaxStatementsLimit">10</entry>
<entry key="jdbc.MinLimit">1</entry>
<entry key="jdbc.statementTimeout">900</entry>
<entry key="log.logging">false</entry>
<entry key="log.maxEntries">50</entry>
<entry key="misc.compress"/>
<entry key="misc.defaultPage">apex</entry>
<entry key="security.disableDefaultExclusionList">false</entry>
<entry key="security.maxEntries">2000</entry>
</properties>

SvDevEDUARD_2,

Инвалидация типов и пакетов дело обычное. Но чтобы apex listener после этого перезапускать пришлось - ни разу такого не было.

Может у вас где-то кеш включен ? В ords вижу: <entry key="cache.caching">false</entry>,
проверьте еще кеш на уровне glassfish, на уровне апекс, и на уровне браузера.

+ пример ошибки привести не помешает.

На уровне браузера кеша нету - ctrl+f5 это подтвердило, да и отправляю POST запрос.

На уровне глассфиша - тоже нету.

В общем час получаю ошибку, пример:




Меняю процесс apex в котором идет вызов, в самом начале вставляю raise_application_error - еще раз сабмичу - появляется текст райза. убираю райз - обратно появляется ошибка состояния пакетов. Помогает только Релоад приложения ORDS - ошибка больше не появляется... так же помогает (ради интереса) - релоад БД.

это при том, что тип валидный - даже самостоятельно зашел и рекомпилил его, в списке инвалидных объектов - ПУСТО!

я делаю вывод что JDBC кеширует

а где посмотреть кеш апекса? Ведь раньше на OHS такого не происходило.

у страницы в приложении Cached:NO

В сессиях апекс-листенера нашел такой код:




в доке сказано:
авторBecause the client-side PL/SQL code cannot reference remote package variables or constants, you must explicitly use the values of the constants. For example, DBMS_SESSION.MODIFY_PACKAGE_STATE(DBMS_SESSION.REINITIALIZE)does not compile on the client because it uses the constant DBMS_SESSION.REINITIALIZE


теперь вопрос - как заставить апекс делать


???

SvDevавтор

ошибки как ошибки, ничего подозрительного не вижу.


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

Но в моем случае, тип уже валидный, а ошибка не пропадает.

SvDevEDUARD_2а где посмотреть кеш апекса? Ведь раньше на OHS такого не происходило.
shared components > security attributes и page attributes.

Покажите apex debug, что там у вас происходит, и проверьте, что в этот же момент, например, в sqlplus нормально процедуры вызываются.

процедуры вызываются без ошибок.

авторВпрочем нашел тему-случай похожий на ваш
нет, это совсем другое и я ее встречал и решал. В его случае ошибка вылезает всегда, не только в апексе.

у меня в полу 4 сессии, так вот жму F5 много раз в браузере - иногда попадаю на сессию, в которой этой ошибки нету, а иногда на ошибку.

В общем я выше уже написал причину ошибки.

SvDev,

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

- Конектюсь Pl/Sql девелопером к БД, беру процесс из апекса и вставляю в тестовое окно - исполняю - не ругается.

- Убиваю сессии Апекс-листенера, обновляю страницу, он создает новые подключения - и ошибка пропадает.

- Ошибка не зависит от типа/пакета, важно только то, что его спецификацию рекомпилили когда в этот момент было обращение из апекса.

- Не все сессию кешируют ошибку, именно та, которая сломалась в пункте выше. Т.е. если jdbc пул выдаст другую - страница отработает нормально.

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

В общем надо экспериментировать, ошибку и то не всегда можно получить. Хоть она и появляется в самый не нужный момент :D