Peter,
We are indeed referring to RM Ack and not Application/Business
App. We discussed this
in the Oracle F2F and we definitely said the latter is outside
our realm. The current proposal
for REL 33 is more like a transport Ack and Jacques and I are
suggesting to make it more like
a RM Ack. So seems like you are in agreement with us and your
only concern is the usage
of words.
Before I list the choices, I just want to re-emphasize that this
(correct usage of words) issue is
sort of orthogonal as we use the same phrase in defining the
Ordering semantics also.
So let me list the choice of words:
1) "make it available to the application/user".
2) "make it available to the next layer".
3) "RMP passing responsibility for the message to the
user"
[I copied this from the Tom's meeting
minutes as Pete W. saying so]
4) "Transferring the responsibility to the next layer".
[i vaguely recollect someone saying
it in the call.]
Does any one have any other suggestions? In the above list, I
prefer option 2 with a comment
that the next layer could be the application user itself.
Thoughts?
-Sunil
"Furniss, Peter" wrote:
I'll
try and state what was worrying me about this on the call last night:Although
the concept "make available to the application/user" can usefully be used
to specify the meaning of a sequence, that doesn't imply that it will necessarily
happen synchronously to the communication. Perhaps best explained by scenario:an
RM receiver receives incoming work overnight and delivers items when they
are asked for by the human-driven application during the day. If messages
arrive as part of a sequence, the software will only offer them to the
user in the right order. It therefore fulfils the sequence requirement
of making them available in order, but the time of making available is
invariably while the RMP is out of communication with the sender.Now
you can try and get round that by claiming that the storage of the message
in the queue in circumstances that would permit its later delivery (i.e.
all prior msgs received) is the point of "making it available to the user",
but that is distinctly artificial and confusing. If you don't bend the
rules like that, then the proposed change would mean that *none* of the
messages received during any connection session (even if they weren't part
of sequences) could be ack'ed until the next night.But
the phrase used often last night was that the ack should be sent when the
receiver can assure the sender that the receiver now has responsibility
for the message, and the sender is absolved of its responsibility. But
that can occur on a message-by-message basis and has nothing to do with
whether the message is yet delivered or deliverable to the user. Actually,
I think the fix to the original problem here is to understand Ack correctly
at the sender side - it's just a RM ack, and means the responsibility has
been transferred. There is the possibility of another acknowlegement -
the message has been delivered, but that's at a higher level - and may
itself be sent back queued.
Peter
------------------------------------------
Peter Furniss
Chief Scientist,
Choreology Ltd
Cohesions 1.0 (TM)
Business transaction management software for application coordination
web: http://www.choreology.com
email:
phone:
+44 870 739 0066 <-- new, from 4 August 2003
mobile: +44
7951 536168
-----Original
Message-----
From: Jacques Durand [mailto:]
Sent: 18 November 2003 22:10
To: ''
Subject: [wsrm] Rel 33: some
thoughts and proposal...
All:
Sorry for a late notification,
but here is a proposal for Rel 33 where a change in
the current semantics for
Acknowledgements is proposed.
This is in the light of
other issues that we are currently trying to solve these days.
We would appreciate having
at least the opportunity to present it to the TC at this meeting, if enough
time...
Again, apologies for late
notice but that is a very recent conclusion of ours,
and we'd like at least to
get early feedback if possible.
Jacques
-----------------------------------------------------------------
We'd like to propose a change
in the semantics of sending an Acknowledgment.
Instead of sending the Ack
when the message is received, the Ack. would be sent
when the message is made
available to the server-side application/user.
After some discussion related
to faults/notifications, we believe this would help
significantly to get both
Sender/Receiver aligned,
and also reduce the need
for additional faults and notifications, always problematic
(e.g. if polling needed).
The advantages we see with
the new proposal are:
- More consistent semantically
because the message is made available to
the user once acked, no
more when buffered.
- Solves the async. failure
notification problems.
- Makes Rel 50, Rel 52,
and Rel 57 simpler.
- the main difference is
for ordered groups, for pending out-of-order sequence.
- all semantics of RM features
(guaranteed delivery, dup elim, ordering) would now be
about conditions of delivery
to application.
We have considered cases
where Acks of received messages would be delayed
due to out-of-order sequences
(not made available to app yet).
To jot some memories back,
this was decision we made at the first F2F
at Redwood Shores and was
reverted back later as it may have payload
affect during retries. We
believe this is a performance issue and
a trade-off on a functional
behavior for a performance one.
Performance can be handled
without problem (see below)
-------- detail:
For implementations that
are concerned about performance hit, an optimization
they could use is to only
retry the lowest un-acked message in a grouped
ordered case, i.e., if msgs.
1,2,3 are sent and Sender hasn't received
acks. for 2 and 3, the Sender
should not retry 3 until they get an ack. for 2.
For RMP impl. that doesn't
worry about retries throttling the Receiver,
they might still send parallel
retries. Either approach won't have any effect
on the end user behavior.
