"bstansberry(a)jboss.com" wrote : | This is what is happening. Question is why a new "valid" node isn't created in the lock() call. | Yes, this is the root of the bug. Where we add nodes if the node does not exist and createIfNotExists == true, we should also set the node to valid if createIfNotExists == true and the node exists but is not valid. "bstansberry(a)jboss.com" wrote : | Hmm, maybe not, I think I see the idea. You're *only* checking for nodes that are "floating in space". Nodes that are still part of the main cache structure, no matter what their status, are OK. | Yes, this is needed to prevent problems with concurrent deletes and puts. "bstansberry(a)jboss.com" wrote : | OT: on the repeek thing -- that seems like quite a bit of overhead since it's repeated on every node from the root down -- for every call. Could that check be limited to the last node in the hierarchy? | Not really - a delete could happen on a parent with a concurrent add on a child with READ_COMMITTED. That said, this could be optimised for R_R and then a separate check on every level for R_C. In the end the ugliness of all this is because locks are a part of a node and if a node does not exist attempting to create one (or concurrently delete one) means that 2 txs may acquire locks on different lock objects, on different nodes, sharing the same Fqn. Stuff that will go away with 3.x as I hope to use a single LockManager that maps locks to Fqn objects. This will still be accessible from the Node - to be compatible with current code - but Node.getLock() will ask the NodeManager for the lock by passing in the Node's Fqn. "bstansberry(a)jboss.com" wrote : | Alternative (which requires SPI change) is to add a boolean "orphan" flag to a node, or to make AbstractNode.deleted an enum with "FALSE, DELETING, DELETED" or something. Some way to change the state of the node itself when it's been cut loose from the tree. Invalid nodes may live longer than just the course of an invocation, and represents more than the partial state of deletion - JBCACHE-1155 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117142#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...