OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue - 33 - proposal to vote on F2F


Diane collected some of the correlation related issues 

33 - Bernd Eckenfels and 37 Yuzo Fujishima , 78 - Yaron Goland (correlation: 8, 26, 31, 66,  96) 

and I think we will discuss them a little bit.

For the issue 33 i propose the follwoing solution:

We accept, that the specification depends on behaviour of the engine implementation and transport protocols, which are
in reality hard to achieve (atomic send, real parallel execution, no delay between activities). Therefore it is good to mention in the specification, that implementors are required to handle this detail.

The proposed text should mean something like:

"The implementation should be able to deal with responses, which are received before the actual receive is activated. This is required to reduce the risk of race conditions, between requesting a service and receiving its response."

I suggest we give this suggestin to the editing team for incooperation.

On the other issues, I plan to have a short presentation "correlations in bpel - what is it and what is open".

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tuesday, August 12, 2003 6:36 PM
To: Eckenfels. Bernd; Dieter Roller
Cc: wsbpel@lists.oasis-open.org
Subject: RE: Issue - 33 - invoke/receive-callback race conditions, even
in the 1.1 sample (p.22)


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.



-----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,

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?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]