[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]