Почему WCF OracleDB получает местоположение, вызванное его FK вместо фактического обновления его таблицы? - PullRequest
Новая
       13

Почему WCF OracleDB получает местоположение, вызванное его FK вместо фактического обновления его таблицы?

1 голос
/ 12 октября 2011

Странное поведение в наших местах приема :

RL_REPRESENTATIVE ожидает уведомления из таблицы REPRESENTATIVE (поля: (PK) id, fname, lname и т. Д.).

RL_CLIENT_REPRESENTATIVE ожидает уведомления из таблицы CLIENT_REPRESENTATIVE (поля: (FK) id_rep, (FK) id_client).

Когда оба местоположения активны, и я фиксирую изменение в таблице CLIENT_REPRESENTATIVE.id_rep, я получаю пару предупреждений (очевидно из RL_REPRESENTATIVE ). 

The adapter "WCF OracleDB" raised an error message. Details "System.InvalidOperationException: The notification query returned an error. Info="Error". Source="Data". Type="Change".
   at Microsoft.Adapters.OracleDB.OracleDBInboundContract.Notification_TryReceive(OracleCommonExecutionHelper executionHelper, Message& wcfMessage)
   at Microsoft.Adapters.OracleDB.OracleDBInboundContract.TryReceive(TimeSpan timeout, Message& message, IInboundReply& reply)
   at Microsoft.ServiceModel.Channels.Common.Channels.AdapterInputChannel.TryReceive(TimeSpan timeout, Message& message)
   at System.ServiceModel.Dispatcher.InputChannelBinder.TryReceive(TimeSpan timeout, RequestContext& requestContext)
   at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.TryReceive(TimeSpan timeout, RequestContext& requestContext)".

и

The adapter "WCF OracleDB" raised an error message. Details "The WCF service host at address oracledb://d01-isis:1521/D01ISIS/Dedicated?CallingTable=REPRESENTATIVE has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host.".

В противном случае процесс, который активируется модификацией в CLIENT_REPRESENTATIVE, происходит без проблем.

(Если вместо этого я обновляю id_client в CLIENT_REPRESENTATIVE - ошибка происходит из другого места приема, которое подписывается на уведомления из таблицы CLIENT.)

Еще две подсказки:

  • Если я отключу RL_REPRESENTATIVE , предупреждения не появятся.

  • Если я обновлю оба CLIENT_REPRESENTATIVE.id_rep и REPRESENTATIVE.fname и зафиксирую оба в одной транзакции, предупреждения не появятся.

Обратите внимание, что ни в одной из таблиц нет триггеров, и все мои тайм-ауты установлены почти на 24 часа.

Я подозреваю, что ограничение FK выполняет свою работу таким образом, что в итоге отправляет уведомление в порт, но я никогда не получаю фактическое сообщение, которое я должен получить.

Вопрос: в Oracle есть параметр, который управляет этим поведением? Кто-нибудь из разработчиков Biztalk сталкивался с этой проблемой?

Ответы [ 2 ]

0 голосов
/ 12 января 2012

В конце концов, решение состояло в том, чтобы изменить флаг во всех местах приема (NotifyOnListenerStart) на «ложь».

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

Изменить: Это побочный эффект FK, изменение его значения, кажется, вызывает уведомление об изменении в таблице, содержащей PK (несмотря на то, что там не было).

0 голосов
/ 22 ноября 2011

Это может быть:

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

Чтобы отследить его, нужно настроить профилирование базы данных и точно определить, какие команды отправляются в каком порядке.

...