MODE-1817 Corrected logic of concurrent removals Added a relatively-simple test case that replicated the exact exception using my hypothesiz…
MODE-1817 Corrected logic of concurrent removalsAdded a relatively-simple test case that replicated the exact exceptionusing my hypothesized scenario. The test creates separate threads toconcurrently remove a specific node and (after synchronizing on aCyclicBarrier) save their changes. Thus, the transient state of eachSession does not see the uncommitted transient state of the otherSession, but both sessions are saved roughly the same time (in differentthreads so different transactions are used). But since both need toacquire the lock on the same parent node, only one session will proceedfirst to successfully remove the node. When the second session proceeds,it no accepts the fact that the node was already removed and proceedsaccordingly.(ACID transactions FTW!)The fix was pretty simple: be aware that attempting to remove an entryin the cache may return null if the entry does not exist (i.e., wasrecently removed).