[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-407) Write locks not acquired on newly created empty nodes

[Manik Surtani (JIRA)]

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

Manik Surtani updated JBCACHE-407:
----------------------------------

    Fix Version/s: 2.1.0.BETA1

> Write locks not acquired on newly created empty nodes
> -----------------------------------------------------
>
>                 Key: JBCACHE-407
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-407
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1.GA, 1.4.0.GA, 1.3.0.GA, 2.0.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.GA, 2.1.0.BETA1
>
>
> When an empty node is created during a put (e.g node "/a" created as a result of a cache.put("/a/1", "key", "value"); call), only a read lock is acquired on the empty node. If the node is created as part of a transaction, the following failure can occur:
> 2 threads, empty cache, READ_COMMITTED
> 1) T1 starts a tx
> 2) T1 invokes cache.put("/a/1", "key", "value1");
> 3) T2 invokes cache.put("/a/2", "key", "value2");
> 4) T1's transaction rolls back
> 5) T2 invokes cache.get("/a/2", "key");  Should get "value2", will get null because the tx rollback will remove node /a and thus /a/2 as well.
> This IMO breaks READ_COMMITTED semantics, as T2 is able to "read" /a (in the sense of seeing it exists and thus can have children appended to it) before the tx that created /a is committed.
> New unit test IsolationLevelReadCommittedTest.testNodeCreationRollback() demonstrates the issue.

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