Occasionally, you may see errors/warnings in the event log when you disable a WCF-Custom receive location which was configured to use the polling feature of the oracle adapter, especially if the polling interval is set to a low value. You would see these errors almost every time you disabled the location, if Polling Interval = 0.One of the errors would be:
"The adapter "WCF-Custom" raised an error message. Details "System.InvalidOperationException: The reply is invalid because the underlying transaction object has been disposed. This occurs if the polling interval expires before receiving a reply. Use a higher value for polling interval."
Another would be:
"The adapter "WCF-Custom" raised an error message. Details "System.Transactions.TransactionAbortedException: The transaction has aborted."
In some cases you may see another error as well: "Connection must be open for this operation".
What's going on?
To understand what's going on, let’s take a closer look at how polling happens in the Oracle Adapter. I'll avoid the gory code level details and present a relatively high level picture.
Simply speaking, at any instant during a running polling scenario, the Adapter may be considered to be in either of the following two states (Figure 1):
Clearly, if the polling interval is small (compared to the time required to complete the tasks in 'Actively Polling' state), at any random point of time the adapter is more likely to be in the 'Actively Polling' state than in the 'Sleeping' state.
Note that Polling Interval = 0 is a special case which tells the adapter to take as much time as it needs to complete the set of steps in the 'Actively Polling' state and poll for the next message as soon as previous transaction has been completed. Thus, in this case, the adapter never goes to the 'Sleeping' state.
Also note that when Polling Interval > 0, there’s no guarantee that the adapter will be able to complete all the above steps within the specified interval. If it is unable to do so, the polling transaction will be aborted and the adapter will go back to poll the next message (if Retry Count > 0). In this case too, the adapter will never go to the ‘Sleeping’ state.
Now if the 'Receive Location' is disabled when the adapter is in 'Sleeping' state, everything would be fine. However, if the adapter happened to be in the 'Actively Polling' state at that point, it may lead to problems. In most cases the following sequence of events will take place at the instant when you disable the receive location:-
The above picture is rather simplified (the thread level details are missing) and may not be completely accurate but I hope it gives some insight into why you see those errors while disabling the receive location and how they are related to the Polling Interval.
Ok, but what are the implications? What do I do if I see this error?
You don’t need to do anything. As explained above, the error is a result of how polling happens and is benign. The only thing you need to keep in mind when you see this error is that the last transaction which the adapter was executing has been aborted. (So, effectively, the last post-poll statement was not executed).