RE: Issue - 33 - invoke/receive-callback race conditions, even in the 1.1 sample (p.22)

["Satish Thatte" <satisht@microsoft.com>]

Bernd,

The grammar may have been challenging because it was constructed by a
non-native speaker ;-)

I was simply saying that I do not see how the use of <flow> creates any
special issues.  

As I read the thrust of your concern, it has to do with ensuring that
messages destined for a process instance are not lost due to races.  We
need to provide a clear statement of expectations from a compliant
implementation to ensure this.

Of course, in any async application protocol, the process cannot be
expected to immediately wait for the response to an async message.
Otherwise we may as well stay with RPC ;-)  So the statement will need
to be focused on the initialization of correlation sets, i.e.,
conversation keys.

Satish

 

-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] 
Sent: Tuesday, August 12, 2003 3:46 AM
To: Satish Thatte; Dieter Roller
Cc: wsbpel@lists.oasis-open.org
Subject: Issue - 33 - invoke/receive-callback race conditions, even in
the 1.1 sample (p.22)

Hello Satish and Dieter,

as the Champion for this issue I am preparing a somewhat cleaner
represenation of the problem, so I am refering to Satish's latest
comment on it:

> So I think it would be helpful to restate your problem making the
assumption of correlation.

I will definitely do this, (and maybe raise another issue, because it is
a rather trivial one).

But I am also interested in better understanding your second comment,
Satish. (which is somewhat gramatically challenging to a non native
speaker, can you clearyfy please?)

> Recasting the example using <flow> is compounding the confusion in my
humble opinion.

If you mean, the flow in the sample would be confusing, then you are
right, I would not introduce that in the sample, but it is another case
where the race condition issue raises its ugly head, thats why i have
mentioned this second (also not working) solution.

Dieter, on the Phone conference where we discussed this issue, you
sounded like you wanted to think of an solution. Anything in your mind,
yet?

I realy do not feel like it is best to force implementations to handle
this case, but on the other side, I do not want to introduce too much
complexity, also?

Greetings
Bernd