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?


The intent of the original authors was pessimistic ;-)
 
Having to handle a fault created by unwarranted optimism seems like a burden that most process designers will balk at.
 
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.
 
Satish
 
 

________________________________

From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Fri 10/17/2003 9:31 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Serializable Scopes Issues?


I've been contemplating serializable scopes for a few minutes, and I have a few concerns that may be issues, or perhaps just inputs into the existing issue asking for the spec to be clearer on how such scopes work. Regardless, I'd like to run these past the TC:

    The spec suggests that serialized scopes should be regarded as being similar to the serialized isolation level in database transactions. Following this suggestion, I can imagine two basic styles of implementation:


*	Pessimistic Lock Style. Scopes acquire suitable read and write locks to assure the isolation characteristics required. 
	
*	Optimistic Lock Style. Scopes, upon closing, check to ensure that variables being updated haven't been already updated by some other (contending) scope (possibly unserialized?) 

The first case leads to the interesting, and in my opinion undesirable, case of serializing execution of concurrent scopes. (It has been asserted elsewhere on this list that serializable scopes can be implemented by a "sufficiently eccentric thread scheduler," which I believe falls into this category.) Thus a flow, executing several concurrent scopes with serialized variable access may in fact execute in a completely serial fashion. We should either a) clarify that this is expected/allowed, or b) direct conforming implementations to avoid this behaviour.

    The second case, optimistic lock style, introduces a new fault type, which occurs when a completing serialized scope attempts to update a shared variable that has been updated by some other scope/process after the completing scope started.  Should we have a standard fault for this scenario? Should it be possible to recover from such an error, through some sort of application retry?

    Finally, would it be useful to allow a serialized scope to have greater control over which shared variables are included in the serialized access group? In other words, would it be better to have a way of explicitly including (or, conversely, excluding) outer variables into (or from) those given serialized access in the scope, rather than including everything? 

    Which brings up another question: should we ban, in <from> general expressions, the ability to indirectly refer to variable names? (I vaguely remember that Arkin (?) raised this issue, possibly in another context, but I can't find it in the issues list.)   

-Ron



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