Delay / Lag between Commit and select with Distributed Transactions when two connections are enlisted to the transaction in Oracle with ODAC

We have our application calling to two Oracle databases using two connections (which are kept open through out the application). For certain functionality, we use distributed transactions. We have Enlist=false in the connection string and manually enlist the connection to the transaction. The problem comes with a scenario where, we update the same record very frequently within a distributed transaction, on which we see a delay to see the commited data in the previous run.

ex.

using (OracleConnection connection1 = new OracleConnection())
 {
  using(OracleConnection connection2 = new OracleConnection())
  {
   connection1.ConnectionString = connection1String;
   connection1.Open();
   connection2.ConnectionString = connection2String;
   connection2.Open();

   //for 100 times, do an update
   {开发者_StackOverflow
    .. check the previously updated value

    connection1.EnlistTransaction(currentTransaction);
    connection2.EnlistTransaction(currentTransaction);

    .. do an update using connection1
    .. do some updates with connection2
   }
  }
 }

as in the above code fragment, we do update and check the previously updated value in the next iteration. The issues comes up when we run this for a single record frequently, on which we don't see the committed update in the last iteration in the next iteration even though it was committed in the previous iteration. But when this happens this update is visible in other applications in a very very small delay, and even within our code it's visible if we were to debug and run the line again. It's almost like delay in the commit even though previous commit returned from the code. Any one has any ideas ?

It turned out that I there's no way to control this behavior through ODAC. So the only viable solution was to implement a retry behavior in our code, since this occurs very rarely and when it happens, delay 10 seconds and retry the same.

Additional details on things I that I found on this can be found here.