Hi David,
I would also like to see a RM implementation, which requests no interactions
from the application.
However, one of the issues that we could not solve so far is determining the
last message.
Say an application needs to send some 10 messages. How can the RM
implementation determine when to terminate the sequence?
The current solution is that the application informs the RM implementation
that this is the last message.
This itself eliminate the possibility of using RM as a switchable module
which has no relation to the application. So if we can find a solution to
this, we can apply the same for recovering process as well.
Thanks,
Jaliya
----- Original Message -----
From: "David Illsley" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, June 20, 2008 12:05 PM
Subject: Re: [Mercury] Mercury restarting (was persistence policy)
FWIW, my mental model of a robust reliable messaging implementation
allows 'client' restart and message resend without any additional
application work, which I think matches that of Dims, Paul and
Sanjiva.
To me it's clear that you can write an Axis2 client which operates
within the context of a transaction. When the transaction commits the
message should be stored safely with associated sequence information
and can then be sent. If for some reason that JVM dies and another
starts with access to the same WS-RM persistent store, there is no
reason that it should not at least attempt to cleanly terminate any
sequences still stored by resending unacknowledged messages to the
destination. (In fact, I think not attempting to re-use the sequence
for new messages is probably a good idea).
I do think it's an interesting question about what should happen in a
non-transactional world. Given the standard model of WS-RM, I think
it's reasonable to retransmit unacknowledged messages regardless. If
the application is really looking for all-or-nothing delivery of an
entire set of messages which seems to be what the 5of10 discussion is
about, WS-RM isn't quite enough.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
