ebBP 3/22/2005: Business Retries and Timeout (wd10/schema 2-22)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Schlegel questions continue. Reference please other emails on 
similar/related topics today. Thanks.

=========================================================
if retry count is equal or larger than 1 and a retry occurs: does a 
retry (from retryCount) reset:

o timeToAcknowledgeReceipt?
o timeToAcknowledgeAcceptance?
=========================================================

mm1: Yes, these are reset although the time to perform is not.  'Time to 
perform' is typically a higher priority than 'acceptance ack' higher 
priority than 'receipt ack'  Historical understanding was that process 
(signal) timeouts are recoverable within retry parameters and not 
recoverable outside of the retry parameters. There have been lengthy 
conversations (and debate) surrounding this issue. Suffice to say, there 
is more to be learned and business requirements to be gleaned as we 
become more sophisticated (hopefully in our lifetime).  John Yunker and 
JJ Dubray can interject here as he was part of those previous 
discussions. Fire away on any concerns or updates/comments. Regards.

Proposed resolution:
Section 4.8.2.3
[as an addition to recent proposed resolutions]
Change from:
In the future after more business requirements are gathered,  the 
business retry count will be further specified in relationship to the 
choreography......

Change to:
In the future after more business requirements are gathered,  the 
business retry count will be further specified in relationship to the 
choreography.
When the business retry is used, the time to acknowledge receipt and/or 
acceptance (given which are used) SHOULD be reset although the 
timetoPerform SHOULD not.  Typically, the timetoPerform is a higher 
priority than Acceptance Acknolwedgement which is a higher priority than 
Receipt Acknowledgement  Process (signal) timeouts are recoverable 
within retry parameters and not recoverable outside of the retry parameters.