[infinispan-issues] [JBoss JIRA] (ISPN-3542) Read Only transaction optimization doesn't work properly for RepeatableRead

William Burns (JIRA) jira-events at lists.jboss.org
Mon Sep 23 18:18:45 EDT 2013


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

William Burns updated ISPN-3542:
--------------------------------

              Status: Pull Request Sent  (was: Coding In Progress)
    Git Pull Request: https://github.com/infinispan/infinispan/pull/2096

    
> Read Only transaction optimization doesn't work properly for RepeatableRead
> ---------------------------------------------------------------------------
>
>                 Key: ISPN-3542
>                 URL: https://issues.jboss.org/browse/ISPN-3542
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 6.0.0.Beta1
>            Reporter: William Burns
>            Assignee: William Burns
>             Fix For: 6.0.0.Beta2
>
>         Attachments: ISPN-3542-patch
>
>
> There is a readOnly optimization that Infinispan does to make sure we don't do a 2PC when there is no data to update.  However the code for this does
> {code}
>    public boolean isReadOnly() {
>       return (modifications == null || modifications.isEmpty()) && (lookedUpEntries == null || lookedUpEntries.isEmpty());
>    }
> {code}
> For repeatable read we always add a value to lookedUpEntries so this optimization never works that isolation level.
> Looking closer it seems we do a 1PC when it is readOnly to clean up values, so there shouldn't be a need to care about lookedUpEntries (my guess is this was done as a way to test for locks).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the infinispan-issues mailing list