Closed doulikecookiedough closed 1 month ago
To resolve the process, unTagObject
will be extracted and moved into storeHashStoreRefsFiles
. Expected exceptions will be re-thrown, and unexpected exceptions will trigger unTagObject
before releasing the lock and bubbling up.
Thread A Thread B
======== ========
: :
uploads object X uploads object X
with pidX with pidX
: :
(gets cid lock) (awaiting lock)
(gets pid lock) :
: :
tagging obj X, :
FAILS ❌ :
catches exception :
UNTAGS obj X ✅ :
: :
(returns cid lock) :
: (gets cid lock)
(returns pid lock) :
: (gets pid lock)
: :
: TAGS obj X ✅
: (returns lock)
DONE
This has been completed via Bug-97: tagObject
Produces Orphaned Object
In the below proposed scenario raised by @artntek ,
tagObject
could possibly produce an orphaned data object.In the example process shown, to add context, there are two paths in which the client could take. 1)
storeObject(InputStream, pid, ...)
where thepid
is locked andtagObject
is automatically called after 2)storeObject(InputStream)
, with no lock, thentagObject
is called verifying the data object is validIn Scenario 1)
storeObject
with a givenpid
, meaning that it would hit the first synchronization lock on thepid
pid
is already being usedpid
can only ever reference one data objectIn Scenario 2) (your described example)
deleteIfInvalidObject
before calling `tagObject)cid
, and thenpid
.pid-cid
combo as expected. Depending on where the failure happened, Thread B will finish the tagging process based on the status of the reference files, and release the lockpid-cid
combo based on the status of the reference files, and release the lockPossible Solution:
Similar to how
storeObject
rejects duplicate store requests for a givenpid
, perhapstagObject
should also do the same. If apid
is in the process of being tagged (it's locked), any subsequent requests to tag apid
should be rejected.There can only ever be 1
pid reference file
, meaning thepid
should only ever appear once in all the cid reference files as well.Since we first lock the
cid
, then proceed to lock thepid
, it sounds reasonable to reject atagObject
request if thepid
is already in the process of being tagged.We may have to re-organize the order, where we attempt to lock the
pid
first.