Title (Goal) ore:aggregation locking
Primary Actor 
Scope 
Level 
Author Justin Coyne
Story (A paragraph or two describing what happens) The ore:aggregation ontology defines a linked-list like structure. However linked lists do not handle concurrent writes gracefully. One actor could update node1.next to be node2 while another actor is trying to update node1.next to be node3.  In hydra we are using a distributed lock (redlock) in Redis to prevent these simultaneous mutations.  Could an api for dealing with atomic access to ore:aggregations be added?

3 Comments

  1. Aaron Birkland

    I'm not entirely sure I follow.   So OAI-ORE does not specifically define a linked list structure, but there has been some effort in the PCDM and Hydra communities using ore:Proxy objects combined with iana:next and iana:prev  to achieve ordering.  Is this what you are referring to?  If so..

    In OAI-ORE proper (which has a lot to say about resolvability of URIs, and which resources have or do not have representations on the web), the expectation is that the proxies are all defined in a resource map, which is a single web resource that defines an aggregation, and contains other properties and resources that characterize it (such as the proxies).  If a Fedora resource were used in a way that were analogous to the ReM, then locking would not be an issue.  The only way to do this right now in Fedora would be through hash URIs, where aggregations and proxies were resources identified by URIs that were fragments of their parent's.  Adding or modifying a proxy would be a matter of PATCH or PUT to the ReM resource, and optimistic locking via etags could be used* (*at least in theory, I'm not sure hash URIs are a documented official pert of Fedora's APIs, nor am I sure their behavior is completely specified)

    An "atomistic" scenario, where aggregations and proxies are all distinct Fedora objects (as shown in this example), is I think what you are describing as a problematic scenario for locking.  In that case, I think API-X could be used in at least two ways:

    • Define an API for locking a container (or use parts of an existing one, such as found in WebDAV), and use API-X to direct requests to the container (or its descendants) through an extension which filters the request.  
      • Define a resource ext:lock on a container through which a client can lock the container, and receive a token in response
      • If the lock is strictly advisory (i.e. not enforced by the extension), do nothing.  Otherwise, requests to a locked  container (and perhaps even children, or descendants)  would be required to be accompanied by the token in order to succeed
      • Define a mechanism (perhaps another interaction with ext:lock, coupled with a timeout) to release the lock
    • Define a ReM representation that incudes an aggregation and all its proxies, and have clients PATCH or PUT to that to modify ordering via proxies in this document.  This would be slick and could be made atomic (and allow nice optimistic locking via etags and the if-match header), but a fair bit of work to implement, and would require your clients to interact with the ReM as if it were an RDFSource.

    It may be possible to avoid needing an extension altogether if transactions can be leveraged in some way, but I'm not entirely up to speed on how JCR or modeshape define concurrent locking semantics, and how much of that is exposed through Fedora's transaction API.

     

     

    1. Elliot Metsger

      What role would an advisory lock play?  I mean, if it isn't a lock enforced by the extension, does that mean that clients are expected to monitor the resource and delay their transaction until the lock is released?

      1. Aaron Birkland

        Advisory lock is just a cheap way to do it with cooperating clients, in cases where explicit (pessimistic) locking is desired.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.