Absolutely.
It is really not easy to comprehend in each case where explicit *-end messages
are necessary or where implicit messages are enough.
In order to keep specifications short, to increase clarity and to reduce the
risk of non-interoperable agents, I also think we should make *-end messages
for NORMAL transaction termination mandantory.
If an implementation is really aware at some point that it wants to close ten
transactions at the same time, it could send all TE messages in a single TCP
frame AND keep the connection still open. I guess the overall performance will
then still be much better than shutting the connection down to imply
transaction termination and then to open a new connection.
Abnormal termination (agent detected a problem in message flow that it cannot
compensate) closing of a connection/transaction must still be possible of
course without a sequence of clean-up messages.
Regards
Martin
I originally marked Application Message End (AME) and Transaction End
(TE) messages as optional: Transaction End (TE) implied the end of
corresponding data flows, while Connection End (CE) implied the end
of all transactions. The motivation was simple: these messages are not
required under some common circumstances, and we want to keep chatter
to the minimum.
First implementation experience showed that it may be confusing to
coders when an AME or TE message should be sent. Not sending a
termination message is likely to cause timeouts because the other side
often has to wait for the end of the message to proceed. However, the
bug may not be detected early enough because some services will not
wait and successfully terminate transactions on their own.
Would anybody be against making these messages required for normal
transaction termination? I think the protocol will be more clear if we
do so. IIRC, Oskar Batuner has already argued that these messages
should be explicit. The drawback is that it would not be possible to
normally terminate a connection with 10 ended transactions without
sending 10 TE messages first, but such a situation is probably rare.
Again, this is a pure "clarity" issue: Correct implementations would
not benefit from having explicit AMEs and TEs, but we might get more
correct implementations or ease development if AMEs and TEs are made
explicit/required.
Thanks,
Alex.