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?
Unfortunately no - there is no contract specifying that a connection has to remain active for the life of the server, or even for the life of a transaction. Connections can be dropped and reestablished between nodes, and the transaction can be completed as if nothing happend. Also, the connection may disappear due to network issues, temporarily or permanently.
In normal operation a user would be expected to keep a single connection active, but that's going to be a best practice, not a requirement.