[infinispan-issues] [JBoss JIRA] (ISPN-1620) A remote get acquired a local lock for the key before writing it to L1 and never releases it

Dan Berindei (Updated) (JIRA) jira-events at lists.jboss.org
Fri Dec 16 07:59:09 EST 2011


     [ https://issues.jboss.org/browse/ISPN-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Berindei updated ISPN-1620:
-------------------------------

              Summary: A remote get acquired a local lock for the key before writing it to L1 and never releases it  (was: A remote get acquired a local lock for the key before writing it to L1)
        Fix Version/s: 5.1.0.CR2
                       5.1.0.FINAL
          Description: 
See the example code in the forum: http://community.jboss.org/message/641760

Because the lock is not released, a subsequent put on the key owner will not be able to invalidate the copy in L1 and so we get an inconsistency between the data in the two caches.

It seems to work fine in non-transactional caches.
             Priority: Critical  (was: Major)
             Assignee: Mircea Markus  (was: Manik Surtani)
    Affects Version/s: 5.1.0.CR1
          Component/s: Locking and Concurrency
      Forum Reference: http://community.jboss.org/message/641760

    
> A remote get acquired a local lock for the key before writing it to L1 and never releases it
> --------------------------------------------------------------------------------------------
>
>                 Key: ISPN-1620
>                 URL: https://issues.jboss.org/browse/ISPN-1620
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Locking and Concurrency
>    Affects Versions: 5.1.0.CR1
>            Reporter: Dan Berindei
>            Assignee: Mircea Markus
>            Priority: Critical
>             Fix For: 5.1.0.CR2, 5.1.0.FINAL
>
>
> See the example code in the forum: http://community.jboss.org/message/641760
> Because the lock is not released, a subsequent put on the key owner will not be able to invalidate the copy in L1 and so we get an inconsistency between the data in the two caches.
> It seems to work fine in non-transactional caches.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the infinispan-issues mailing list