[
https://issues.jboss.org/browse/ISPN-5631?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-5631:
----------------------------------------
[~enrico.olivelli], as you rightly say, this is the result of the async event
implementation. The idea is that the removals will eventually reach the client. It'd
be very expensive for the server to block the outcome of say, a put call, until all
connected clients would have consumed the event, which in the case of near caching,
it'd result in a removal.
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)