[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: issue regarding the "fresh" attribute (forward from John L.)
> From: Krishna Yellepeddy [mailto:kyellepe@us.ibm.com] I came across the above when trying to make sense of the "Fresh" attribute. By design, sometimes it will work, and sometimes it will fail. It is impossible for a client to predict when a get for a fresh object has succeeded. And it is impossible for a server to determine if a client wants a fresh object when the client performs a get operation. Assuming that atomic batch execution is out of the question, one possible design solution would be to include the "fresh" attribute in the get request from the client. If the server receives a get request for a UID with fresh set to true, (and assuming that the server performs the get operation atomically - which may or may not be true, but is certainly preferable to atomic batch execution - and any half decent server claiming to support the fresh attribute would need to support an atomic get), then it can return the object if it is indeed "fresh", or an error if it is not. As Krishna stated in his response to Denis above, other Locate operations followed by Get operations have the same problem. It's obvious that any stateless system (and probably many stateful ones too) that require at least two distinct operations (Locate and Get) without containing them within a single transaction is prone to this problem. Are there any other use cases (other than Locate-fresh/Get) that we should consider fixing in 1.1? Is this something that we should add to the 2.0 list of things to fix? John ---------------------------------------------------------------- --------------------------------------------------------------------- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]