Einstein shows that simultaneity isn't possible ;) Lamport shows the problems of trying to do synchronization in a distributed system (check out Time, Clocks and the Ordering of Events" paper from the late 1970s.
I know the idea of a "fudge factor" seems appealing, but as I already said, it's going to be difficult to manage across different types of infrastructrue (please, not yet another configuration option!). 10ms may be "enough" for traditional ethernet, but may be overkill for microchannel. And when timeouts are typically measured in seconds anyway, it's probably not going to do much in narrowing the window of vulernability.
Tom Jenkinson wrote:
Ideally the subordinate will never need to timeout the transaction as the parent will have done it for it. If the parent timesout the transaction at the subordinate it is removed from the subordinates reaper so that is ideal.
As you say, in certain scenarios a delay of <insert your fudgefactor here> is realistic (say a stop the world GC in the parent) at that point we will get the heuristic scenario in the parent where the child has already timed out the tx. I don't think we can safely leave the transaction laying around indefinitely in the subordinate waiting for the parent to try to check if it is timeoutable as we can't be sure the parent hasn't died and will never recover.
Is remoting permanent connection oriented? Can we rely on a notification in remoting to say that the connection between the an application server has broken as a result of a server crash?