[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-955) Restore ability to insert and remove child nodes with only a read lock on the parent

Restore ability to insert and remove child nodes with only a read lock on the parent ------------------------------------------------------------------------------------ Key: JBCACHE-955 URL: http://jira.jboss.com/jira/browse/JBCACHE-955 Project: JBoss Cache Issue Type: Feature Request Security Level: Public(Everyone can see) Affects Versions: 1.4.1.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Critical Fix For: 2.0.0.GA, 2.0.0.BETA1, 1.4.1.SP1 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.