[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE : setResourceProperties atomicity
I'm sitting here at the WS-Notification meeting, and the following topic has just come up. The atomicity of setResourceProperties() in WSRP is currently undefined (I can't get to the current spec right now (no net) to point at a particular section, sorry). An implementation is free to either do them all at once, guaranteeing atomicity, or to do them one at a time, so that some of them might have worked and others did not at the end of the invocation. In other words, it's a QoS issue as to whether a given implementation decides to do it one way or the other. This seems like a fine thing, except that apparently there is not yet a plan for either a) a metadata/policy assertion which indicates a given resource will do setResourceProperties in an atomic (or not) way, or b) a way to indicate in a given setResourceProperties() invocation that the requester requires atomicity. I would like to raise an issue that both of these things should be specified in WSRP. In particular, I'm suggesting that the group: 1) Define a normative way to indicate in metadata that a resource will do atomic setResourceProperties() invocations (this is basically a boolean element with a well known QName) 2) Define a boolean "atomic" flag/attribue on the setResourceProperties() operation, the semantics of which indicate that a successful result means ALL sets were done, and a failed result means NO sets were done. IMHO, without this stuff, the usefulness of a single set operation for multiple resource properties is severely restricted. --Glen
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]