[ http://jira.jboss.com/jira/browse/JBCACHE-955?page=all ] Brian Stansberry closed JBCACHE-955. ------------------------------------ Fix Version/s: (was: 2.0.0.GA) Resolution: Done -- 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

[ http://jira.jboss.com/jira/browse/JBCACHE-955?page=all ] Brian Stansberry updated JBCACHE-955: ------------------------------------- Description: In 1.4.1.GA JBC introduced tighter locking semantics wherein the insertion or removal of a node required a write lock on the parent. In recent previous versions (and maybe always) only a read lock was required. The 1.4.1.GA behavior provides greater correctness, but at a cost of lesser concurrency. Some applications written assuming the old behavior will not function properly with the new behavior. Speaking in db isolation terms, let's say a non-repeatable-read means a tx reads a node's *data map* twice and gets different results. A phantom read means a tx reads a node's *child map* twice and gets different results. Conceptually, a JBC node represents both a "row" (data map) and a query result set (children map -- set of rows that share a common characteristic that the parent represents). (I know this analogy is inexact, but, ...). In 1.4.0.SP1, REPEATABLE_READ meant you wouldn't get non-repeatable-reads, but could get phantom reads. With 1.4.1, you also don't get phantom reads (at least with respect to a node's immediate children). But, in many cases this behavior is unneeded and undesirable, and JBC no longer offers the old behavior. This JIRA will restore the old behavior for the pessimistic locking use case. A new cache configuration flag LockParentForChildInsertRemove will be added. If set to false, the 1.4.0.SP1 behavior of only requiring the RL will be restored. The default value of the flag will be false. was: In 1.4.1.GA JBC introduced tighter locking semantics wherein the insertion or removal of a node required a write lock on the parent. In recent previous versions (and maybe always) only a read lock was required. The 1.4.1.GA behavior provides greater correctness, but at a cost of lesser concurrency. Some applications written assuming the old behavior will not function properly with the new behavior. Speaking in db isolation terms, let's say a non-repeatable-read means a tx reads a node's *data map* twice and gets different results. A phantom read means a tx reads a node's *child map* twice and gets different results. Conceptually, a JBC node represents both a "row" (data map) and a query result set (children map -- set of rows that share a common characteristic that the parent represents). (I know this analogy is inexact, but, ...). In 1.4.0.SP1, REPEATABLE_READ meant you wouldn't get non-repeatable-reads, but could get phantom reads. With 1.4.1, you also don't get phantom reads (at least with respect to a node's immediate children). But, in many cases this behavior is unneeded and undesirable, and JBC no longer offers the old behavior. This JIRA will restore the old behavior for the pessimistic locking use case. A new cache configuration flag LockParentForChildInsertRemove will be added. If set to false, the 1.4.0.SP1 behavior of only requiring the RL will be restored. The default value of the flag will be true. Revised main entry to state that the default value for the flag will be 'false'. We switched to that after the JIRA was closed. -- 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

[ http://jira.jboss.com/jira/browse/JBCACHE-955?page=comments#action_12352808 ] Jaka Jaksic commented on JBCACHE-955: ------------------------------------- All the method comments in TreeCache and TreeCacheMBean still say "The default value is <code>true</code>", although the default value is in fact false. -- 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