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] Serializable Scopes Issues?


Ron,

I don't buy the three days vs one day example - I don't see which
interfering shared variable access is essential in that example.

What did you have in mind for the handling of concurrency faults?
Retry?  Failure?  Some custom code?

Satish

 

-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] 
Sent: Monday, October 20, 2003 2:57 PM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Serializable Scopes Issues?

Satish Thatte wrote:

>The intent of the original authors was pessimistic ;-)
>
So the glass was always half empty, eh? :-)

It would be good to capture this in the new-and-improved description of 
serializable scopes. It will be interesting to see what the thinking of 
the TC will be, concerning this new (to me, at least) restriction.

>Having to handle a fault created by unwarranted optimism seems like a
burden that most process designers will balk at.
>
I was thinking that this would be an implementation-specific fault; I 
assume your proposal is that the "pessimistic locking" style be made 
manditory; that is, implementations are not free to use the optimistic 
locking style.

What of the problem with serialized execution of such scopes? Optimistic

locking would permit concurrent execution in cases where pessimistic 
locking wouldn't. The example I had in mind was the (by now) classic 
travel agency example. If three activities (serializable scopes) are run

concurrently to book a flight, hotel, and rent-a-car, the pessimistic 
locking model might have them execute in serial fashion, while 
optimistic locking would enable concurrent execution. If each activity 
took, say, one day, then pessimism would result in three days to do the 
booking, while optimism would perform it in one day. The price of blind 
optimism would be the a nasty concurrency fault, of course.

> 
>I agree that we must ban "variable names are themselves variables" to
(among other things) allow the touchpoints of serializable scopes to be
statically determined.  Declaring the touchpoints explicitly should be
unnecessary.
>
Either ban indirect variable naming, or lock everything! Ugly indeed. 
This was what suggested to me that more selective locking mechanisms 
might be useful.

-Ron





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