[infinispan-issues] [JBoss JIRA] (ISPN-5631) NearCache: ability di wait for other Java HotRod clients to invalidate lazy near cache on remove

[Enrico Olivelli (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103455#comment-13103455 ] 

Enrico Olivelli commented on ISPN-5631:
---------------------------------------

Maybe it could be a flag:

Cache<String, String> cache = ...;
cache.getAdvancedCache().withFlags(Flag.WAIT_REMOTE_NEAR_CACHES_INVALIDATION)
    .put("last-login-date", "2012.08.31");

A timeout should be configurable for this kind of operations on the nearcache client side config.

Even if it would be expensive for the server I think that this feature will be very useful because with such an ability the hotrod client + nearcache can be used in simple transactions with Last Resource Optimization technique: the client would perform a commit on sql database (or other transactional resource, such as JMS queue)  and then invalidate the cache. 

In fact we use such a tecnique for SQL databases and ActiveMQ queues, and using Infinispan as cache provider sometimes it appens that another (remote) thread which reads  data from the nearcache after receiving a JMS message it get a stale value

Another useful flag (maybe it would be better to file JIRA issue) is would be a flag to skip the NearCache for "important gets", that is for "get operations" that you want to be in synch with the "real data" stored on the cache servers.

> NearCache: ability di wait for other Java HotRod clients to invalidate lazy near cache on remove
> ------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-5631
>                 URL: https://issues.jboss.org/browse/ISPN-5631
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 7.2.3.Final
>         Environment: Java hotrod client/server
>            Reporter: Enrico Olivelli
>              Labels: hotrod-java-client
>
> When a Java HotRod client invalidates (remove) an entry it is possibile that this action is not propagated with enough speed to other clients due to the async nature of event notifcations used by NearCache, an so it is possibile that another client looks up a stale entry from its near cache.
> A typical "writer client" scenario is:
> - update the database and commit the transaction
> - invalidate the entry which represents the updated (only a "remove")
> The "reader" procedure is:
> - lookup in the cache (nearcache, backed by the remote Infinispan cluster)
> - in case of "cache miss" perform a lookup on the database and write the entry in the cache



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)