[infinispan-issues] [JBoss JIRA] Resolved: (ISPN-72) Asynchronous Cache API

[Manik Surtani (JIRA)]

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

Manik Surtani resolved ISPN-72.
-------------------------------

    Fix Version/s: 4.0.0.ALPHA3
                       (was: 4.0.0.BETA1)
       Resolution: Done


> Asynchronous Cache API
> ----------------------
>
>                 Key: ISPN-72
>                 URL: https://jira.jboss.org/jira/browse/ISPN-72
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Core API, RPC
>            Reporter: Manik Surtani
>            Assignee: Manik Surtani
>             Fix For: 4.0.0.ALPHA3, 4.0.0.GA
>
>
> Unscheduled for now.
> From Tim Fox:
> E.g. imagine I set a value in the cache, by the time I get the response that the value has been set in the cache, I also need to know that it's been replicated to another node so I can have the redundancy guarantees for high availability.
> One way to do that is just to block the thread that calls set() until the replication has been performed synchronously to the other node and returns, however that will involve a network round trip per set.
> What would be nice would to be able to get the acknowledgements of replication back asynchronously in a different stream, e.g.
> S = Set in cache, A = acknowledgement of replication of Set() in cache
> With a blocking approach you'd have
> S1
> A1
> S2
> A2
> S3
> A3
> I.e. you wait for the ack of the set before calling the next set, which involves a network RTT per set.
> With a non blocking (pipelined) approach, you call your sets in quick succession without waiting for a response, then some time later you'd get your ack back.
> E.g. chronologically something like:
> S1
> S2
> S3
> S4
> S5
> S6
> S7
> A1
> A2
> S8
> A3
> S9
> A4
> S10
> S11
> A5
> Since you're not blocking, you can use the throughput of the network without being limited by its latency.
> This is the kind of thing we in messaging replication, i.e. when someone sends a load of message one by one we can't individually do a network RTT per message (it would be too slow) to replicate them, but they still need the guarantee the message has reached the backup before they get the acknolwedgement of send back.
> Manik:
> Returning a Future would probably be the way to do this, but I would need to think about what the API would look like though, since the API should look and behave the same regardless of cache mode/cluster config used.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira