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]

Reply via email to