As you mentioned the SequenceIDs should be handled by the RM EPM and that is the way it is done. The idea behind the sequenceKey concept was giving the client some flexibility to decide how his messages will be divided into sequences. If the sequenceKey is different the messages will be sent in two different sequences.
Even if the sequenceKey is equal if they do not share the same storage, the two client applications will send two create sequence messages and the messages will go in two different sequences.
If they share the same storage. To applications should be synchronized correctly, so that no two messages are given the same message number.
Thanks,
Chamikara
On 2/24/06, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote:
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]
>
