RE: Issue - 52 - Deadlocks and Internal Messaging

You should not be doing a busy wait. You should use links for synchronization. I thought we agreed that we need realistic cases that validate going beyond this. Isn’t that why this issue is on “pause”?

From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Tuesday, September 30, 2003 9:53 AM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: RE: Issue - 52 - Deadlocks and Internal Messaging

Aren't we just moving the lump around the carpet? Lacking the ability to use internal messaging isn't the programmer who needs to communicate between flows forced to use global variables? In which case they can easily create code that live locks:

<flow>

</while>

</sequence>

</while>

</sequence>

</flow>

Unless there is a third suggestion that avoids both live locks and deadlocks then the only two options on the table are either global variables or internal messaging, with all the warts both imply. In which case I believe the selection should be made based on which of the two solutions will be easiest for programmers to use. Global variables require the programmer to manually implement the asynchronous features that are implicit in messaging. Furthermore internal messaging is more consistent with the general BPEL zeitgeist for dealing with communication. Therefore internal messaging seems the least worst option.

Yaron

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Monday, September 29, 2003 9:33 PM
To: ygoland@bea.com; wsbpel@lists.oasis-open.org
Subject: RE: Issue - 52 - Deadlocks and Internal Messaging

Yaron,

If all messaging operations time out then of course you will not have a deadlock, you will have faults. Which is arguably worse, since internal messaging should be “correct by design” if it is meant to synchronize concurrent activities, as opposed to communications with unpredictable real partners. What exactly is the process designer supposed to do with internal messaging timeout faults that occur as a result of faulty design which would have led to deadlock in the absence of timeouts?

Creating a potential deadlock is obviously easy

<flow>

<sequence>

       <receive internal Foo ..>

       <send internal Bar>

</sequence>

<sequence>

       <receive internal Bar ..>

       <send internal Foo>

</sequence>

</flow>

Although realistic examples will be more disguised.

Satish

From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Monday, September 29, 2003 12:06 PM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: Issue - 52 - Deadlocks and Internal Messaging

Satish,

    I'm not 100% sure what you mean when you say that internal messaging causes deadlock. One of my basic assumptions is that any messaging operation that does not complete within a certain period of time will eventually time out. So I'm not clear on how internal messaging could cause deadlocks.

What I can see is how one could create a livelock. For example:

<flow>

   <sequence>

      <while condition="bpws:getVariableData(Success1) <> "done">

         <scope>

            <faultHandlers>

               <catch faultName="ProprietaryTimeOutFault"><empty/></catch>

            </faultHandlers>

            <sequence>

               <invoke partnerLink="TalkingToSelf" operation="getFoo" inputVariable="FooIn" outputVariable="FooOut">

               <assign><copy><from>Done</from><to variable="Success1"/></copy></assign>

            </sequence>

         </scope>

      </while>

      

   </sequence>

   <sequence>

      <while condition="bpws:getVariableData(Success2) <> "done">

         <scope>

            <faultHandlers>

               <catch faultName="ProprietaryTimeOutFault"><empty/></catch>

            </faultHandlers>

            <sequence>

               <invoke partnerLink="TalkingToSelf" operation="getBar" inputVariable="BarIn" outputVariable="BarOut">

               <assign><copy><from>Done</from><to variable="Success2"/></copy></assign>

            </sequence>

         </scope>

      </while>

      

   </sequence>

</flow>

Is this what you meant when you aid deadlock?

    Yaron

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Thursday, September 25, 2003 9:24 PM
To: ygoland@bea.com; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 67 - Clarify semantics of serializable scopes

Yaron,

Perhaps I misspoke. I thought in the context of the discussion on Issue#52, you had commented that deadlocks are already possible in BPEL 1.1, in response to my claim that internal messaging would introduce them for the first time.

My apologies if I mistakenly interpreted that to mean serializable scopes in BPEL 1.1 already allow deadlocks because of the locking they imply.

Satish

From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Wednesday, September 24, 2003 3:44 PM
To: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 67 - Clarify semantics of serializable scopes

I'm not sure what the issue is referring to vis a vis any comments I made. I'm not aware of serializable scopes introducing any new deadlock issues that aren't already in BPEL [1]. After all Serializable scopes are really nothing more than instructions to the thread scheduler. So in theory any behavior you could see as a result of a serializable scope could be reproduced by a sufficiently eccentric thread scheduler.

    Yaron

[1] The use of serializable scopes and links could cause deadlocks. But the authors understood this and so explicitly banned the use of links that cross serialized boundaries in section 12.5.



-----Original Message-----
From: ws-bpel issues list editor [mailto:peter.furniss@choreology.com]
Sent: Wednesday, September 24, 2003 1:28 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 67 - Clarify semantics of serializable scopes

This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 67 - Clarify semantics of serializable scopes

Status: open
Categories: concurrency control
Date added: 24 Sep 2003
Submitter: Satish Thatte
Date submitted: 23 September 2003
Champion: Satish Thatte
Document: Language specification, section 13.6
Description: There has been some recent discussion regarding the concurrency control semantics of serializable scopes. Yaron Goland had also raised a question regarding the possibility of deadlock among serializable scopes. This section needs additional wording to clarify these issues.
Links: Ron Ten-Hove, 15 Sep 2003
Changes: 24 Sep 2003 - new issue

To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 67 - [anything]" or is a reply to such a message.

To add a new issue, see the issues procedures document.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.

wsbpel message

Issue - 67 - Clarify semantics of serializable scopes