Doug,
It seems to me that once the MSH has deposited a message in its persistent
store, it has fulfilled its obligation to deliver the message to the
application. If it then goes ahead and deletes the message, it may be
pulling the rug out from under the application. Unless the MSG team wants
to prescribe a transactional protocol between the MSH, persistent store,
and application, the MSH must keep its paws off the message once it has
deposited it in the persistent store.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
Doug Bunting <dougb62@yahoo.com> on 12/11/2001 12:47:14 PM
To: ebxml-msg@lists.oasis-open.org
cc:
Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
Arvola,
I disagree; the wording is fine as it is.
If the example you've described occurs, the To Party MSH is not operating
correctly. The TimeToLive value is intended to be the time by which
(end-to-end, application-to-application, whatever you want to call it)
delivery must be complete. That may mean the To Party MSH discards a
message after it has been persisted in some storage (but not delivered to
its application).
Going further, your previous recommendation made sense though the example
was also slightly incorrect. In that example, a message found in
persistent
store after crash recovery might (MUST) be discarded due to an expired
TimeToLive value. Of course, we can't say anything about how long it might
take an application to process a message...
thanx,
doug