[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [bt-spec] Votes for 13 March call
Votes for myself, Doug Bunting, the one sending this message, et cetera. (Should be fairly obvious since OASIS process doesn't support proxy votes). - Issue 29: Redirection AGAINST - current proposal adds value by providing the "carrier protocol" option for REDIRECT but complicates the situation by adding the FAULT/redirect. Changes as they stand do not explain REDIRECT versus FAULT/redirect clearly. When a request / response message (such as PREPARE / PREPARED) travels over the Superior:Inferior relationship, why can't the receiver respond with Fault/redirect? On other relationships, if the receiver has the address of the sender, should they also send a REDIRECT message? In general, why are there two mechanisms to carry the same information? This "feels like" creating a new message to cover the difference between a PREPARED message sent to register an autonomous decision versus one sent in reply to PREPARE. Allowing REDIRECT (explicitly or implicitly using the new and good carrier protocol option) to be used in reply seems much cleaner. - Issue 41: ENROL/no-rsp-req FOR - Issue 60: address-as-role or releasers FOR B (releasers) - Issue 97: Version identification on xml namespaces FOR - Issue 99: PREPARE_INFERIORS and FAULT(InvalidInferior) FOR B (PREPARE is an intermediate state and doesn't imply the overall transaction will be confirmed or cancelled, why worry about implementations choosing to optimistically PREPARE various inferiors? Disagreements between the Terminator and Decider on the valid inferiors don't always indicate application errors. This situation is made more common because RESIGN isn't forwarded to the Terminator. Only the Decider forgets about resigned inferiors.) caveats - This issue closes most of the problems described but worsens the problem we encountered with CONFIRM_TRANSACTION/report-hazard and PREPARE_INFERIORS/report_hazard (issues 50 and 107). The proposed text doesn't prevent the Decider making a Cancel decision due to invalid inferior identifiers and doesn't describe handling of errors encountered contacting a particular inferior "known" to the Decider. If a Decider chooses to cancel based on encountered errors or received FAULT messages (including invalid inferiors), are FAULT messages sent to the Terminator? What changes when report_hazard is "false"? (I think report_hazard determines whether HAZARD messages are sent but doesn't affect FAULT messages but want to be sure.) For the second problem, think of crashed inferiors. The Decider and Terminator agree on the valid inferiors list but don't know about a particular inferior's failure. So, are errors encountered contacting known inferiors during the PREPARE phase of CONFIRM_TRANSACTION handled through HAZARD, FAULT/InvalidInferior or something else? What changes when report_hazard is "false"? Part of this may be answered by requiring a decision be made prior to sending PREPARE but that prevents some common 2PC implementations and invalidates our current PREPARE_INFERIORS followed by CANCEL_TRANSACTION option. thanx, doug
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC