Details

      Description

      Essentially, it is about supporting eventual consistency in Infinispan. Currently Infinispan is strongly consistent when using synchronous distribution mode. Each data owner receives updates synchronously so anyone anywhere on the cluster doing a GET will see the correct value. The only exception is during a rehash (when a new node joins or leaves), that consistency is eventual since the GET may reach a new joiner who may not have applied state it receives from its neighbours yet. However this is hidden from users since the GET is sent to> 1 data owner and if an UnsureResponse is received (determined by the fact that a new joiner responds and the new joiner wouldn't have finished applying state), the caller thread waits for more definite responses.

      However, there is a use case for being eventually consistent as well: the main benefits being speed and partition tolerance. E.g., if we use distribution in asynchronous mode, the writes become much faster. However, anyone anywhere doing a GET will have to perform the GET on all data owners, and compare the versions of the data received to determine which is the latest. And if there is a conflict, to pass back all values to the user.

      So in terms of design, what I have in mind is:

      • All cache entries are versioned using vector clocks. One vector clock per node.
      • When a node performs a GET, the GET is sent to all data owners (concurrently), and the value + version is retrieved from each.
      • If the versions are all the same (or they can be "fast forwarded"), the value is returned
      • Otherwise, all potential values and their versions are returned
      • A resolve() API should be provided where application code may provide a "hint" as to which version should be "correct" - which will cause an update.
      • In terms of implementation, this will touch the DistributionInterceptor, InternalCacheEntry and relevant factories, some config code (since this should be consistency model should be configurable), and a new public interface.

        Gliffy Diagrams

          Issue Links

            Activity

            manik Manik Surtani created issue -
            manik Manik Surtani made changes -
            Field Original Value New Value
            Assignee Manik Surtani [ manik ] Filip Rogaczewski [ rogaall ]
            rogaall Filip Rogaczewski made changes -
            Status Open [ 1 ] Coding In Progress [ 3 ]
            manik Manik Surtani made changes -
            Link This issue depends ISPN-1116 [ ISPN-1116 ]
            pmuir Pete Muir made changes -
            Workflow jira [ 12441645 ] GIT Pull Request workflow [ 12449955 ]
            manik Manik Surtani made changes -
            Priority Major [ 3 ] Blocker [ 1 ]
            manik Manik Surtani made changes -
            Assignee Filip Rogaczewski [ rogaall ] Manik Surtani [ manik ]
            Priority Blocker [ 1 ] Critical [ 2 ]
            Hide
            NadirX Tristan Tarrant added a comment -

            As mentioned, we should look into extending the get() and put() semantics (through advancedacache) to support the required consistency level. For reference, Cassandra uses ANY, ALL, ONE, QUORUM, LOCAL_QUORUM, EACH_QUORUM. Look here for a description: http://wiki.apache.org/cassandra/API

            Show
            NadirX Tristan Tarrant added a comment - As mentioned, we should look into extending the get() and put() semantics (through advancedacache) to support the required consistency level. For reference, Cassandra uses ANY, ALL, ONE, QUORUM, LOCAL_QUORUM, EACH_QUORUM. Look here for a description: http://wiki.apache.org/cassandra/API
            manik Manik Surtani made changes -
            Fix Version/s 6.0.0.FINAL [ 12314721 ]
            Fix Version/s 5.1.0.BETA1 [ 12313469 ]
            Fix Version/s 5.1.0.FINAL [ 12313470 ]
            manik Manik Surtani made changes -
            Status Coding In Progress [ 3 ] Open [ 1 ]
            sbs-jira-plugin Jive JIRA Integration made changes -
            mircea.markus Mircea Markus made changes -
            Fix Version/s 7.0.0.Final [ 12319335 ]
            Fix Version/s 6.0.0.Final [ 12314721 ]
            manik Manik Surtani made changes -
            Link This issue depends on ISPN-3198 [ ISPN-3198 ]
            mircea.markus Mircea Markus made changes -
            Component/s Core API [ 12312421 ]
            Component/s Distributed Cache [ 12312422 ]
            mircea.markus Mircea Markus made changes -
            Component/s Transactions [ 12312432 ]
            Component/s Locking and Concurrency [ 12312427 ]
            velias Vlastimil Eliáš made changes -
            Workflow GIT Pull Request workflow [ 12449955 ] GIT Pull Request with Triage workflow [ 12612541 ]
            Hide
            rcd Rich DiCroce added a comment -

            Is this still slated for Infinispan 7? I can see it's been bumped from 5.1 to 6 to 7 so far...

            Show
            rcd Rich DiCroce added a comment - Is this still slated for Infinispan 7? I can see it's been bumped from 5.1 to 6 to 7 so far...
            dan.berindei Dan Berindei made changes -
            Fix Version/s 8.0.0.Final [ 12319336 ]
            Fix Version/s 7.0.0.Final [ 12319335 ]
            Hide
            dan.berindei Dan Berindei added a comment -

            I bumped the target version again, to 8.0, since we haven't made any progress on this yet.

            Show
            dan.berindei Dan Berindei added a comment - I bumped the target version again, to 8.0, since we haven't made any progress on this yet.
            NadirX Tristan Tarrant made changes -
            Assignee Manik Surtani [ manik ]
            NadirX Tristan Tarrant made changes -
            Priority Critical [ 2 ] Major [ 3 ]
            NadirX Tristan Tarrant made changes -
            Fix Version/s 9.0.0.Final [ 12326667 ]
            Fix Version/s 8.0.0.Final [ 12319336 ]

              People

              • Assignee:
                Unassigned
                Reporter:
                manik Manik Surtani
              • Votes:
                5 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Time Tracking

                  Estimated:
                  Original Estimate - 1 minute
                  1m
                  Remaining:
                  Remaining Estimate - 1 minute
                  1m
                  Logged:
                  Time Spent - Not Specified
                  Not Specified

                    Development