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: RE: [wsbpel] Incosistency in Link Join condition Evaluation specification


Title: Message
Dear Prasad, Danny and others,
 
Are you able to formulate an issue for me to lodge as received, or are we not yet at the point of having convinced ourselves that there is an issue to be formulated?
 
Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination       www.choreology.com
 
Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
Sent: 27 January 2005 21:42
To: Dieter Koenig1
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Incosistency in Link Join condition Evaluation specification

Hi Dieter,

Issue 6 is speaking to a process terminating without waiting for the completion of all "unnecessary" concurrent activities.

The issue I am raising is with a specific activity continuing after the joinCondition is met even when all source activities for the links coming into have not completed. Specifically when an activity needs only one of its source activities to be completed as in the case of an implicit-join, it seems it is unnecessary (with serious performance implications) to require that all source activities must be complete prior to evaluating the join condition. If there are cases that in fact desire to wait for all source activities to complete, I  think we should make that something one needs to explicitly capture in the join condition definition.

I think the following text in the section 12.5.1 second paragraph capture the spirit of what I am calling for:

"If the explicit join condition is missing, the implicit condition requires the status of at least one incoming link to be positive".

The solution to this could be as simple as adding an attribute that qualifies joinCondition.  Should the be
joinCondition evaluated only after all source activities are complete (default?) or each time the status of an incoming link changes (a la @suppressJoinFailure). Enabling this would be very beneficial IMO.

Thanks.

Prasad

Dieter Koenig1 wrote:
IMO, the text in 12.5.1:

"If an activity that is ready to start in this sense has incoming links,
then it does not start until the status of all its incoming links has been
determined and the (implicit or explicit) join condition associated with
the activity has been evaluated."

DOES constitute a control dependency.

Continuing when the final outcome of the join is determined but before all
source activities have completed, is IMO something we do not have so far
and addressed in issue 6.

Kind Regards
DK



                                                                           
>From: Prasad Yendluri <pyendluri@webmethods.com>                                                  >To: dannyv@tibco.com                    
>cc: wsbpel@lists.oasis-open.org         
>Subject: Re: [wsbpel] Incosistency in Link Join condition Evaluation specification                       
                                                                           
No where in the spec we say control dependency exists regardless of
joinCondition. So, we have scope for interpretation and so, things look
fine to you when they did not to me.  We need to minimally correct that.

Let us look at what it really means for the control dependency to exist
regardless of the joinCondition. So I want to wait for all source
activities to complete (successfully or not) and I want to proceed only if
the join-condition evaluates to true when it is implicit join or OR join on
all links. That is fine but this is modeling a very special case IMO,
generally we don't wait for things to complete, the success or failure
status of which we don't care about. Even if one cared one should perhaps
capture that via an explicit  AND joinCondition rather than rely on an
implicit syntactic sugar.

Where as more simpler (perhaps common) case would be to wait on any one (or
n < total) of the source activities to complete successfully (like a
barrier in threads). How can one model that?

It seems we have an issue here.

Regards, Prasad

Danny van der Rijn wrote:
      Things look fine to me.  For (2) and (3), you have to realize that a
      control dependency exists regardless of the joinCondiiton.  If you
      don't want the control dependency, don't draw a link.  (4) is
      referring to an explicit piece of code (the Initial Example) in which
      your stipulation ("...is only one of the incoming links...") is not
      correct, since there is only one link target.

      Danny

      Prasad Yendluri wrote:
            Hi,

            We have the following text dispersed in sections 12.5.1 and
            12.5.2 that results in an inconsistent specification of
            evaluation of Link Join conditions. The spec states:

            (1) Section 2.5.1: Every activity that is the target of a link
            has an implicit or explicit “join condition” associated with
            it. If the explicit join condition is missing, the implicit
            condition requires the status of "at least one" incoming link
            to be positive (see below for an explanation of link status).

            So, the implicit join is an "OR" and the join condition
            evaluates to true as soon as the status of one of the incoming
            links to the activity is positive.

            (2) Section 2.5.1:  If an activity that is ready to start in
            this sense has incoming links, then it does not start until the
            status of "all" its incoming links has been determined and the
            (implicit or explicit) join condition associated with the
            activity has been evaluated.

            If it is an implicit join why should the activity not start as
            soon as one (or more) of its incoming links goes to a positive?
            Why should it wait until the status of all incoming activities
            has been determined?

            (3) Section 2.5.1: For each activity B that has a
            synchronization dependency on A, check whether:
            o        B is ready to start (except for its dependency on
            incoming links) in the sense described above.
            o        The status of all incoming links for B has been
            determined.

            Again why the requirement to wait until the status of all
            incoming activities is determined?

            (4) Section 12.5.2: If one of these invocations were to fault,
            the status of the outgoing link from the invocation would be
            negative, and the (implicit) join condition at the target of
            the link would be false, but the resulting bpws:joinFailure
            would be implicitly suppressed and the target activity would be
            silently skipped within the sequence instead of causing the
            expected fault.

            If the link that was set to false (due to the failure) is only
            one of the incoming links to an "implicit join", shouldn't the
            join condition evaluate to false only when all other links to
            the join also evaluate to false.

            It seems either the parts related implicit join in (2),(3),(4)
            above or incorrect or (1) itself was not correct. I believe 1
            is correct.

            Either way it seems we need to fix this. Comments?

            Regards, Prasad

  


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