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
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:
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.
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?
Aaron Birkland
Advisory lock is just a cheap way to do it with cooperating clients, in cases where explicit (pessimistic) locking is desired.