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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: spurious contradictions


I've found another rathole with autonomous confirm and false positive
detection of contradiction.

At present (and for some while), we have an autonomous confirm (or cancel)
by the participant (usually, though not necessarily following expiry of a
timeout) signalled to the superior by the CONFIRMED (or CANCELLED) message.
This means if they cross that there is no special action required - both
sides send one, receive one and don't have to worry.


It is also possible, especially with one-shots, for an ENROL + app-response+
VOTE/ready/10/confirm to get lost - this should lead to the cancelling of
the atom (either deliberately by the application when the application
response is bad, or when the coordinator timeout goes off and the
coordinator realises there is no point (if the application is still
waiting).  However, if the participant then goes ahead with its threat to
confirm on *its* timeout, this will show up as an unexpected CONFIRMED (or
INFERIOR_STATUS/confirmed ) at the superior side. There may well be no
record of the atom at the superior at this point - however, the receipt of
the message in the "unknown" state means that the superior can detect that
there was a contradiction - even though it doesn't know who with.

However, with appropriate timings of log-delete, you can get an apparent
contradiction when in fact there hasn't been one :
..
..
..

						P :log-ready
C  <--- VOTE/ready/T/confirm ---- P


C: log-confirm
C --- CONFIRM --X (lost)

					    P: log-auto-confirm
C <-----   CONFIRMED  ------ P
C: log-delete

Z  <--- INFERIOR_STATUS/confirmed -----	P
contradiction detected !

You can get other detailed sequences to do this. The arrival of
INFERIOR_STATUS/confirmed (or CONFIRMED itself) says "contradiction", but
actually there wasn't.


Choices:

1) we could have it that the message sent on autonomous confirm is not
regarded as replying to the CONFIRM, but there must be another message sent
only after the CONFIRM is received, *and after the inferior has deleted/
rewritten the log to show that the CONFIRM has arrived,

2) We could deem that this doesn't matter, since the known atom *did*
complete successfully, and the apparent contradiction concerns only an
(apparently) unknown atom.

3) Something else I haven't thought of (but note there are lots of
variations on 1), depending on exactly which messages are used or changed)


Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC