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

[Manik Surtani (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBCACHE-955?page=all ]

Manik Surtani updated JBCACHE-955:
----------------------------------

    Fix Version/s: 2.0.0.GA

> 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.

-- 
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