<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi guys<br><br></div>I'm working on an intermittent failure in NodeMoveAPIPessimisticTest and I think I've come across what I think is underspecified behaviour in AtomicHashMap.<br>
<br></div>Say we have two transactions, tx1 and tx2, and they both work with the same atomic map in a pessimistic cache:<br><br></div>1. tx1: am1 = AtomicMapLookup.get(cache, key)<br></div>2. tx2: am2 = AtomicMapLookup.get(cache, key)<br>
</div>3. tx1: am1.put(subkey1, value1) // locks the map<br></div>4. tx2: am2.get(subkey1) // returns null<br></div>5. tx1: commit // the map is now {subkey1=value1}<br></div>6. tx2: am2.put(subkey2, value2) // locks the map<br>
</div>7. tx2: commit // the map is now {subkey2=value2}<br><div><div><div><div><div><br><div><div>It's not clear to me from the AtomicMap/AtomicHashMap javadoc if this is ok or if it's a bug...<br><br></div><div>
Note that today the map is overwritten by tx2 even without step 4 ("tx2: am2.get(subkey1)"). I'm pretty sure that's a bug and I fixed it locally by using the FORCE_WRITE_LOCK in AtomicHashMapProxy.getDeltaMapForWrite. <br>
<br>However, when the Tree API moves a node it first checks for the existence of the destination node, which means NodeMoveAPIPessimisticTest is still failing. I'm not sure if I should fix that by forcing a write lock for all AtomicHashMap reads, for all TreeCache reads, or only in TreeCache.move().<br>
<br></div><div>Cheers<br></div><div>Dan<br><br></div></div></div></div></div></div></div></div>