Oracle B2B – b2b.rowLockingForCorrelation
By cdwright on Dec 21, 2012
In cases where the latency between the outbound EDI document and the subsequent inbound acknowledgment is very low, a race condition will likely occur when B2B tries to update the document state in the B2B_Business_Message table. The result is the status of the original EDI document remains in either a MSG_WAIT_FA or MSG_WAIT_ACK state indefinitely if no retry value has been set, or it evolves to a state of MSG_ERROR after the retry interval and all the retry attempts have expired.
In these cases, no exceptions occur so you won’t find the problem by searching log files. The problem tends to manifest itself as one of the two following conditions:
Condition 1: The original EDI document (such as a HL7, X12, or EDIACT), when configured to handle a Functional Acknowledgment, remains in a state of MSG_WAIT_FA after the functional acknowledgement has in fact been received and is itself in a MSG_COMPLETE state.
If the retry interval and retry attempts parameters for the FA are set to values greater than zero in the B2B trading partner agreement or the SSHI endpoint configuration, the state of the original EDI document will eventually evolve to MSG_ERROR while the FA will be shown as MSG_COMPLETE
Condition 2: The original EDI document (such as a HL7, X12, or EDIACT) remains in a state of MSG_WAIT_ACK after the MDN has in fact been received and is itself in a MSG_COMPLETE state.
If the retry interval and retry attempts parameters for acknowledgments in the transport protocol section of the delivery channel or endpoint configuration is set to values greater than zero in the B2B trading partner agreement or the SSHI endpoint configuration, the state of the original EDI document will evolve to MSG_ERROR while the MDN will be shown as MSG_COMPLETE
To avoid these conditions, add the following property to the b2b properties section of Enterprise Manager for SOA Suite:
b2b.rowLockForCorrelation = true
This property applies row level locking to the B2B_Business_Message table forcing the ACK to wait for the initial write to complete before attempting to update the row itself. You may observe some slow down in the average transaction time due to the fact that B2B will be using row level locking, But the impact should only be minor.