Hi Daniel,
Let me answer your question.
In this situation, we will end up in a mess. Sequence ID should be a unique
entity for a given sequence of messages.
If the user (client) sets them manually then from the RM Destination side,
only a set of ordered messages (may be from both clients as a mix) will be
used to invoked the service and rest will be discarded as duplicates.
However, if the client really want to do it, then better to set the sequence
ID as well as message numbers by itself. E.g
Client One: SeqID ABC, Msg Nos 1,2,3
Client Two: SeqID ABC, Msg Nos, 4,5,6
IMHO, sequence ID should be handled by the RM Endpoint manager automatically
without letting client application to this ambiguous situation.
Thanks,
Jaliya
----- Original Message -----
From: "Daniel Millwood" <[EMAIL PROTECTED]>
To: "Chamikara Jayalath" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Friday, February 24, 2006 5:29 AM
Subject: Re: Sandesha2 store interface, transactions and synchronization
Hi Chamikara,
Thanks for the reply. I will checkout the latest code and look at the
transaction model again.
I have one more question following on from 2) below.
If I have 2 client applications both sending to the same URI and both
clients have set the Sandesha2ClientAPI.SEQUENCE_KEY to the value
"sequence1", will those 2 client applications share the same sequence? If
so, are the 2 client applications expected to do their own synchronization
so that only one webservice invocation is made at a time?
Thanks, Dan
"Chamikara
Jayalath"
<[EMAIL PROTECTED] To
l.com> Daniel Millwood/UK/[EMAIL PROTECTED]
cc
24/02/2006 03:45 [email protected]
Subject
Re: Sandesha2 store interface,
transactions and synchronization
Hi Daniel,
Sorry abt the late response. Please see my comments below.
On 2/21/06, Daniel Millwood <[EMAIL PROTECTED] > wrote:
Hello,
Can someone answer a couple of questions I have about the Sandesha2 code.
1) From looking back through the mail archives, there were some emails
on
the need to make the transactional updates to the store atomic so that a
persistent store will always recover with a valid set of data. Is there
still a plan to make this change?
As an example, in the outbound message case, the NextMsgNo
SequencePropertyBean is updated in a different transaction to the one
used
to store the message. If NextMsgNo was read at 4 and updated to 5, then
the system crashed before message 4 was stored, after a restart, the next
outbound message would read nextMsgNo at 5 and update it again to 6 and
there would be a gap in the sequence, as no message 4 was ever stored.
This was a bug. I fixed this by bringing both these under that the same
transaction. Please take a new checkout.
2) Looking at the current code, I couldnt see any synchronization to
stop
two parallel threads sending using the same sequence from both assigning
the same sequence number for their message.
Example:
Thread 1 enters SandeshaOutHandler.getNextMsgNo() for Sequence XYZ
Thread 2 enters SandeshaOutHandler.getNextMsgNo() for Sequence XYZ
Thread 1 reads nextMsgNo=3 from nextMsgNoBean for Sequence XYZ
Thread 2 reads nextMsgNo=3 from nextMsgNoBean for Sequence XYZ
Thread 1 calls nextMsgNoBean.setValue(4); for Sequence XYZ
Thread 2 calls nextMsgNoBean.setValue(4); for Sequence XYZ
Thread 1 returns 3 from SandeshaOutHandler.getNextMsgNo () for Sequence
XYZ
Thread 2 returns 3 from SandeshaOutHandler.getNextMsgNo() for Sequence
XYZ
Is this multi-threaded case a valid use-case for Sandesha2 and the Axis2
engine?
If so, has any thought been given as to how to make the code thread safe?
Thanks, Dan
As u mentioned your scenario is about two parallel threads sending
messages
for the same sequence. In your client code you must be trying to invoke
the
same stub using different threads. To my knowledge, Axis2 stubs are no
thread safe. So the way to go is doing your own synchronization, before
calling the stubs. When you do this, the above scenario will not occur.
Thanks,
Chamikara
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
