OTS 1.1 NO IDEA Avatar
  1. OMG Issue

OTS11 — ots - resource & recoverycoordinator no longer there

  • Key: OTS11-19
  • Legacy Issue Number: 3671
  • Status: open  
  • Source: Choreology Ltd. ( Peter Furniss)
  • Summary:

    Failures during the commit exchanges can lead to recovery attempts trying to
    get to either Resources or RecoveryCoordinators that no longer exist
    (depending on exactly when the failure occurred). They can also lead to
    attempts to access one or the other when the object instance isn't

    If a target Resource really does not exist, the coordinator can infer that
    an earlier Commit got through and the response was lost, so the coordinator
    can stop trying (and forget it's own logs). If a RecoveryCoordinator does
    not exist, the Resource can infer that the transaction rolledback.

    This behaviour seems to be summarised in the Failures and Recovery section.
    In the section "If No Heuristic Decision is Made", describing Resource
    behaviour, it explicitly states that OBJECT_NOT_EXIST to replay_completion,
    it will know the transaction rolledback, whereas COMM_FAILURE means it must
    try again.


    1) There is no corresponding statement for a Coordinator (or recovered
    coordinator - strictly a client of Resource) getting exceptions on
    attempting to access the Resource. Should there be ?

    2) Is it only OBJECT_NOT_EXIST that will definitively mean the object does
    not now and never will again exist. What about INV_OBJREF ? Can all orb's
    be trusted not to throw these exceptions if the object is being still
    possibly going to be recreated by some recovering server ?

    3) replay_completion supplies a Resource parameter, which (since there is
    ("implicitly")) a separate RecoveryCoordinator for each Resource, can be a
    replacement for the original Resource reference. Should this be explained
    more fully.

    4) If the (original) commit did get through, is the Resource perhaps
    expected to remain available for some time (how long), rather than become
    non-existent. (The protocol would work if any request targetted on an
    extinct Resource caused the temporary creation of an instance that just
    replied to the commit, rather than the coordinator treating OBJECT_NOT_EXIST
    as "gone away")

  • Reported: OTS 1.0b1 — Thu, 1 Jun 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT