Не всегда получается использовать XA источники к базам данным.
Иногда мы вынуждены использовать локальные транзакции и с помощью их вызывать процедуры которые содержат в себе операции коммит. Такой источник данных содержит в себе сразу несколько проблем главная их которых это то, что мы не можем откатить такие изменения, а в случае ошибки при вызове не можем знать, что успело, а, что нет закоммитися в базу.
Как следствие, если такой вызов закончился неудачей, нам не остаётся ничего другого, как вручную разбираться в базе, что произошло. И главное, мы не можем автоматически попробовать повторить такую операцию.
По умолчанию визарды JDeveloper предлагают такую конфигурацию для DB адаптера в файле composite.xml
<property name="jca.retry.count" type="xs:int" many="false" override="may">4</property>
<property name="jca.retry.interval" type="xs:int" many="false" override="may">1</property>
<property name="jca.retry.backoff" type="xs:int" many="false" override="may">2</property>
<property name="jca.retry.maxInterval" type="xs:string" many="false" override="may">120</property>
что предполагает автоматическое повторение в случае ошибки в количестве 4 раз.
Если мы попробуем указать первый параметр как 0, то получим ошибку при деплое.
Так же есть, глобальный параметр (в EM) GlobalTxMaxRetry (The maximum number of times a GLOBAL_RETRY FabricInvocationException can be retried before bubbling up). Его можно установить в 0, но наши параметры из composite.xml переопределяют это значение и повторы при вызовах всё равно будут.
При ошибке таймаута в её описании:
This exception is considered retriable, likely due to a communication failure. To classify it as non-retriable instead add property nonRetriableErrorCodes with value "1013" to your deployment descriptor (i.e. weblogic-ra.xml). To auto retry a retriable fault set these composite.xml properties for this invoke: jca.retry.interval, jca.retry.count, and jca.retry.backoff. All properties are integers. ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully
to determine a resolution.
Есть информация об установки атрибута nonRetriableErrorCodes в weblogic-ra.xml DB адаптера, но его установка, по крайней мере у меня не исключила повторные запросы.
Выход оказался простым. Нужно просто удалить из composite.xml информацию о четырёх свойствах jca.retry.* для каждого адаптера.
Надо понимать, после этого берётся только значение из GlobalTxMaxRetry, где его нулевое значение исключает не желательные для нас попытки повторного вызова процедур при сетевых сбоях.
Иногда мы вынуждены использовать локальные транзакции и с помощью их вызывать процедуры которые содержат в себе операции коммит. Такой источник данных содержит в себе сразу несколько проблем главная их которых это то, что мы не можем откатить такие изменения, а в случае ошибки при вызове не можем знать, что успело, а, что нет закоммитися в базу.
Как следствие, если такой вызов закончился неудачей, нам не остаётся ничего другого, как вручную разбираться в базе, что произошло. И главное, мы не можем автоматически попробовать повторить такую операцию.
По умолчанию визарды JDeveloper предлагают такую конфигурацию для DB адаптера в файле composite.xml
<property name="jca.retry.count" type="xs:int" many="false" override="may">4</property>
<property name="jca.retry.interval" type="xs:int" many="false" override="may">1</property>
<property name="jca.retry.backoff" type="xs:int" many="false" override="may">2</property>
<property name="jca.retry.maxInterval" type="xs:string" many="false" override="may">120</property>
что предполагает автоматическое повторение в случае ошибки в количестве 4 раз.
Если мы попробуем указать первый параметр как 0, то получим ошибку при деплое.
Так же есть, глобальный параметр (в EM) GlobalTxMaxRetry (The maximum number of times a GLOBAL_RETRY FabricInvocationException can be retried before bubbling up). Его можно установить в 0, но наши параметры из composite.xml переопределяют это значение и повторы при вызовах всё равно будут.
При ошибке таймаута в её описании:
This exception is considered retriable, likely due to a communication failure. To classify it as non-retriable instead add property nonRetriableErrorCodes with value "1013" to your deployment descriptor (i.e. weblogic-ra.xml). To auto retry a retriable fault set these composite.xml properties for this invoke: jca.retry.interval, jca.retry.count, and jca.retry.backoff. All properties are integers. ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully
to determine a resolution.
Есть информация об установки атрибута nonRetriableErrorCodes в weblogic-ra.xml DB адаптера, но его установка, по крайней мере у меня не исключила повторные запросы.
Выход оказался простым. Нужно просто удалить из composite.xml информацию о четырёх свойствах jca.retry.* для каждого адаптера.
Надо понимать, после этого берётся только значение из GlobalTxMaxRetry, где его нулевое значение исключает не желательные для нас попытки повторного вызова процедур при сетевых сбоях.
