[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Serializable Scopes Issues?
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:
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]