[
http://jira.jboss.com/jira/browse/JBCACHE-956?page=comments#action_12351941 ]
Manik Surtani commented on JBCACHE-956:
---------------------------------------
This actually does not work for optimistic locking and here's why.
Whenever a node is added, the following happens:
1) Parent read into TX Workspace (call this parentW)
2) New node created in workspace
3) New node added to parentW's child map
4) At commit, parentW's child map is used to overwrite parent's child map
Because of step 4, there is no way we can support concurrent adds/removes on parent nodes
without implementing a diffing/merging algorithm for child maps. Step 4 has to be an
overwrite since we don't know whether part of the tx also involved removing children
unless we have a merging algo.
I agree that this is pretty crap and we do need something more sophisticated here, but I
don't think it is correct to do in 1.4.1.SP1.
See JBCACHE-961
Use LockParentForChildInsertRemove flag to control Optimistic node
versioning
-----------------------------------------------------------------------------
Key: JBCACHE-956
URL:
http://jira.jboss.com/jira/browse/JBCACHE-956
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Affects Versions: 1.4.1.GA
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 1.4.1.SP1
See JBCACHE-955 for background on locking issues related to inserting and removing child
nodes.
This JIRA is to look into using JBCACHE-955's LockParentForChildInsertRemove flag to
control whether the insertion or removal of a child node affects a workspace node's
data version.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira