OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

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

Subject: RE: [kmip] Groups - Group as a managed object (KMIP-GroupProposal-02182011.ppt) uploaded

> From: Krishna Yellepeddy [mailto:kyellepe@us.ibm.com] 
> Sent: Thursday, 19 May 2011 4:30 AM
> To: Pochuev,Denis
> Cc: kmip@lists.oasis-open.org
> Subject: RE: [kmip] Groups - Group as a managed object
> (KMIP-GroupProposal-02182011.ppt) uploaded
>> From: "Pochuev,Denis" <Denis.Pochuev@safenet-inc.com> 
>> To: Krishna Yellepeddy/Austin/IBM@IBMUS 
>> Cc: "'kmip@lists.oasis-open.org'" <kmip@lists.oasis-open.org> 
>> Date: 05/16/2011 12:55 PM 
>> Subject: RE: [kmip] Groups - Group as a managed object
>> (KMIP-GroupProposal-02182011.ppt)   uploaded
>> 6. It seems that [Locate "fresh=true"] operation would
>> always have to be batched with a Get request. Otherwise
>> another client can preempt the first one and issue a Get
>> for the object, whose UUID has been returned by the
>> response to the initial [Locate "fresh=true"]. The
>> picture would get even more complicated if the answer
>> to the previous question (5) is "Yes". 
> Answer: I agree, but this is not an issue unique to the
> Groups proposal.  Any other Locate call with attributes
> where the attributes can be changed between the Locate
> and the next operation has the same issue.  Even batching
> does not solve the issue as there is noting in KMIP which
> requires a batch to be executed as a single atomic
> transaction. 

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.
If use of the fresh attribute can lead to the wrong outcome for a client, and as there is no way for client or server to know that the outcome is wrong, shouldn't we consider either dropping the feature, or if possible, designing it properly so that it will work?

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 Leiseboer                    QuintessenceLabs Pty Ltd
Chief Technology Officer          Suite 23, Physics Building #38
P: +61 7 5494 9291                Science Road
F: +61 2 6125 7180                Australian National University
M: +61 409 487 510                Acton, ACT 0200 Australia
mailto:jl@quintessencelabs.com    www.quintessencelabs.com

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