"unless the current data is write locked" only works if you do have something like your Intention lock. (In my earlier post, I said " I'd argue that get() needs to establish a hard read lock (even when the node isn't there, even if the isolation mode is READ_COMMITTED) that is upgraded to a write lock on put() and then released/downgraded afterwards.", so yes, I agree that it is one possible solution)
But I'd argue that replacing existing data on a putFromExternalRead() is never useful. a) I check the cache and find nothing there b) I read data from the database c) I go to write my data back to the cache and find something there already already Assuming that all database updates also cause cache updates, the data I find at step c) can't be older than the data I read at step b), so there is no point in replacing it. The only thing that I'm aware of that the intention lock does better than "don't replace" is handle the case of entity deletion. (it might also work better in the case where we are invalidating across the cluster rather than replicating- I haven't thought through that situation thoroughly) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977572#3977572 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977572 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
