OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[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