RE: [business-transaction] Issue - maint-11 - Allow repeat CANCELLED

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Title: Message

This came up as a problem for our implementers - they were having to send INFERIOR_STATUS/unknown in certain recovery and retry cases. Since INFERIOR_STATUS/unknown can be a trigger for generating HAZARD(possible), this caused false positive warnings. Since, in fact, the inferior wasn't unknown, this seemed silly.

 

I've tested this out on the state tables in the spec (adding the states as proposed), and it all works. I'll put up the revised state tables shortly.

 

Peter

-----Original Message-----
From: Furniss, Peter
Sent: 23 March 2004 12:51
To: business-transaction@lists.oasis-open.org
Subject: [business-transaction] Issue - maint-11 - Allow repeat CANCELLED

This issue has been added to the btpm issue list. The issues list is posted as a Technical Committee document to the OASIS BTP TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the BTP TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - maint-11 - Allow repeat CANCELLED

Status: open
Date added: 22 Mar 2004
Submitter: Peter Furniss
Date submitted: 22 March 2004
Description: The existing state tables insist that an Inferior that has cancelled must immediately go to a state where there is no knowledge of the transaction (z) and respond to a repeated CANCEL with an INFERIOR_STATE/unknown message. In reality, an iimplementation is likely to still hold state which would allow it to reply CANCELLED again, for some time - eventually it will probably forget the cancelled transaction completely. Forcing immediate ignorance is unnecessary - implementations should be allowed, but not required to send a repeat CANCELLED if a repeat CANCEL is received.
Submitter's proposal: Add additional state z2, entered on sending CANCELLED where this currently transits to z. If an imbound message is received, transit to a new query state (y3), which is exitted by resending CANCELLED, reverting to z2. Disruption (loss of volatile information) should cause a transition to existing z. (Thus the current behaviour can be treated as a disruption I.)
Changes: 22 Mar 2004 - new issue

---

To comment on this issue, please follow-up to this announcement on the business-transaction@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - maint-11 - [anything]" or is a reply to such a message.

To add a new issue, please email to the issues list maintainer (Peter Furniss).

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/business-transaction/members/leave_workgroup.php.