persistDuration has/should have nothing to do with ConversationId.
A conversation can last for a very long time. persistDuration
is just an artifact of reliable messaging, indicating the
minimum time that a party/parties have agreed to persistently
store the requisite information needed to ensure that no
duplicate messages are delivered.
Cheers,
Chris
David Fischer wrote:
> I seem to be missing something. The end of a conversation is controlled by
> persistDuration, isn't it? I think the ConversationId is held in persistent
> store with the MessageId (at least in the case of MessageOrdering). Along with,
> or in, the MessageId record, there must be a persistDuration field. When the
> last message in that conversation is deleted from the persistent store
> (persistDuration has passed), wouldn't the ConversationId automatically go with
> it? If there are still messages waiting because they are out of order, would
> they not also be deleted when persistDuration expires? If you are concerned
> with messages going away too quickly, then make persistDuration long.
>
> There is nothing forbidding another later message to be sent with the original
> ConversationId but the message order would not be of concern since all the
> previous messages have expired anyway.
>
> Or, are you saying ConversationId is held somewhere else?
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
> Sent: Monday, December 03, 2001 3:54 AM
> To: Dan Weinreb; mwsachs@us.ibm.com
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
> Dan and Martin,
>
> My proposal's purpose is not management of ConversationId by MSH itself.
> Its purpose is prevention of invalid ConversationId and acquisition of
> timing information of the end of conversation in MSH. Because message
> order is guaranteed per conversation. If higher layer (application or
> middleware) gives MSH invalid ConversationId, MSH will fail in guarantee
> of message order. And also if MSH can't know when the conversation
> finishes, MSH can't decide that when the conversation's sequence number
> information can be released from MSH's resource.
>
> So I can withdraw (1) in my proposals below, but I'd like to keep (2) as
> my proposal. Because if higher layer gives MSH the status information
> (Start, Middle, End or Alone), sending MSH and receiving MSH can check
> invalid ConversationId and can know when the conversation finishes.
>
>
> On Thu, 29 Nov 2001 19:39:33 +0900
> SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> wrote:
>
>>The specification of ConversationId element on page 20 has two problems:
>>
>>1) The value of the ConversationId element is determined by the Party.
>>
>> ConversationId is very important for guarantee of message order.
>> Because message order is guaranteed per each conversation. Thus MSH
>> instead of Party should determines and manages the value of the
>> ConversationId to prevent invalid ConversationId value. I propose
>> following change:
>>
>> Line 823-825
>> ... The Party initiating a conversation determines the value of the
>> ConversationId element that SHALL be reflected in all messages
>> pertaining to that conversation.
>> |
>> V
>> ... The Party indicates start and end of conversation to MSH. The
>> value of the ConversationId element is generated and managed by the
>> MSH.
>>
>>2) Receiving MSH can't know the end of conversation.
>>
>> Receiving MSH holds received conversation's ConversationId in its
>> persistent storage for guarantee of message order. However receiving
>> MSH has not any way to know the end of conversation. Thus receiving
>> MSH don't know when ConversationId's information can be removed from
>> its persistent storage.
>>
>> To resolve the problem, I propose to add status attribute to
>> ConversationId element. The status attribute takes one of following
>> three values:
>> Start: First message in messages belong with the conversation.
>> Middle: A message except for first and last message in messages
>> belong with the conversation.
>> End: Last message in messages belong with the conversation.
>> Alone: First and last message in the conversation which consist
>> of only one message. It MUST be specified when the
>> conversation have only one message.
>>
>
>
> Regards,
>
> --
> SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
> TEL:+81-45-476-4590(ext.7128-4241) FAX:+81-45-476-4726(ext.7128-6783)
> Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>