ebBP 5/23/2005: Comment re: Multiple Joins on a Fork? (wd-2-0-1-03)

[Monica J Martin <Monica.Martin@Sun.COM>]

We discussed fork-join in our call 19 April 2005, as the detailed 
comment was received after the vote started for the v2.0 Committee 
Specification. [1] We decided at that time that no substantive change 
would be considered, and other improvements could be considered for v3.0.

Section 3.4.11.1
Change from:
For XOR or OR Fork, this does not rule out different joins pertaining to 
states emerging from a Fork or Forks. This allows a split in processing 
between a group all of which must be done and one where at least one (or 
more) is sufficient for the transition. The behavior of Forks over Joins 
is implementation specific.

Change to:
For XOR or OR Fork, this does not rule out different joins pertaining to 
states emerging from a Fork or Forks. This allows a split in processing 
between a group all of which must be done and one where at least one (or 
more) is sufficient for the transition. As bounded by Fork semantics, 
multiple joins may be allowed for a fork (multiple dependencies exist).  
The behavior of Forks over Joins may be handled by monitoring 
capabilities (for example, detection via static analysis).

Reassess in v3.0.

Please provide any comments or changes/additions. Talk to you on Tuesday.

[1] Reference Meeting Notes post: 
http://lists.oasis-open.org/archives/ebxml-bp/200504/msg00056.html

>> Nagahashi: I suppose we can safely say multiple Joins are allowed for 
>> a Fork, without making its behavior implementation dependent. I think 
>> semantics of Fork is clear enough: multiple dependencies to enable 
>> next activity. BSI must wait until all (or any) of incoming 
>> transitions are executed.
>> One thing BPSS author must be careful is a dead-lock. Combining XOR 
>> Forks and multiple Joins, author can easily create unsatisfiable 
>> Fork... Tools MAY help detect such structure with static analysis.
>
> mm1: Kenji, this is important to provide a public comment on this as 
> the documents have been uploaded and the vote will initiate today. 
> This is really an editorial change as the question has been partially 
> discussed in the TC.
>
>>> Moberg: I agree that we have not ruled having different joins 
>>> pertaining to
>>> states emerging from a fork (or forks). It makes some features
>>> (waitForAll) somewhat murky to apply, but it would allow a split in
>>> processing between a group all of which must be done and one where at
>>> least one (or more) is sufficient for the transition. Would work OK 
>>> with
>>> Xor forks I think. Would be OK with Or forks I think.
>>> I guess we could say that the behavior of spreading forks over joins is
>>> implementation dependent.
>>>
>>> -----Original Message-----
>>> From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] Sent: 
>>> Wednesday, April 13, 2005 1:44 PM
>>> To: Dale Moberg; Kenji Nagahashi; Kenji Nagahashi; Jean-Jacques Dubray;
>>> Jean-Jacques Dubray
>>> Subject: Multiple Joins on a Fork?
>>>
>>> Kenji: Can single fork apply to multiple joins?  I think this is 
>>> possible but we have not discussed this case. Do we address this in 
>>> the section on Fork and Join as an edge-case? Corresponding text 
>>> doesn't address it either way so are we silent on this?
>>>
>>>     It MUST only be used in the case where all outgoing transitions 
>>> from
>>>     the Fork have incoming transitions to the Join.
>>