RE: Issue - 52 - Deadlocks and Internal Messaging

["Yaron Goland" <ygoland@bea.com>]

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>
   <sequence>
      <while condition="bpws:getVariableData(FooReady) <> 'YES'">
         <wait for=X/>
      </while>
      <assign><copy><from>YES</from><to
variable="BarReady"/></copy></assign>
   </sequence>
   <sequence>
      <while condition="bpws:getVariableData(BarReady) <> 'YES'">
         <wait for=X/>
      </while>
      <assign><copy><from>YES</from><to
variable="FooReady"/></copy></assign>
   </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>

      <!-- Wait to receive a getBar incoming message and then do useful work
-->

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

      <!-- Wait to receive a getFoo incoming message and then do useful work
-->

   </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
<http://www.oasis-open.org/apps/org/workgroup/wsbpel> 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
<http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> 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
<http://www.choreology.com/external/WS_BPEL_issues_list.html> constant URL. 


Issue - 67 - Clarify semantics of serializable scopes


Status: open
Categories: concurrency control 
Date added: 24 Sep 2003
Submitter: Satish Thatte <mailto:satisht@microsoft.com> 
Date submitted: 23 September 2003
Champion: Satish Thatte <mailto:satisht@microsoft.com> 
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
<http://lists.oasis-open.org/archives/wsbpel/200309/msg00169.html> 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.

<<attachment: winmail.dat>>