Alex, thanks for monitoring various discussion threads and sharing these problems with the rest of the dev community.
>> As a short-term solution for [2] I suggest to force reads from a primary > node inside optimistic serializable transactions. Totally agree on this. Anyway, consistency and predictable behavior matter most. Also, it shouldn't affect performance anyhow dramatically. >> I think it may be better to make read-through and entry expiry a > partition-wide operation with the underlying cache guarantees. That's a pain in the neck! As you properly mentioned, an in-memory data grid sitting on top of an external database is still our dominating use case. So, a partition-wide operation assumes that if a record is read from a CacheStore than its value will be replicated to all the primary and backup copies, right? - Denis On Fri, Mar 6, 2020 at 12:58 AM Alexey Goncharuk <alexey.goncha...@gmail.com> wrote: > Anton, > > > > >> In short, the root cause of this issue is that there are > configurations > > >> that allow a key to be stored on primary and backup nodes with > different > > >> versions. > > Faced with the same problem during ReadRepair development. > > > > >> I suggest to force reads from a primary > > >> node inside optimistic serializable transactions. > > It looks like a proper fix (read-from-backup= ... && !read-through). > > > > >> I would suggest to revisit the > > >> read-through and TTL expiry semantics. > > Do we really need these features? > > - we have great full-featured consistent persistence, what's the point to > > use limited-featured inconsistent persistence via the external database? > > Can we get rid of this feature at 3.0? > > - Expiry policy is expensive (slowdown the cluster) and does not > guarantee > > the in-time removal, and always may be replaced by proper design (state > > machine, query, eviction, in-memory cluster restart, etc). > > > > Caching a 3rd-party persistence is one of the most widely used Ignite > use-cases, I am sure we cannot drop this. Perhaps, it makes sense to > separate the caching scenario in an explicit configuration and cache mode. > Probably, even separate cache and database cases. > > As for expiry policy - I agree that a user can always implement it on > application level, but a user can always implement transactions as well. If > we already have a feature and we can fix it properly, why not keep it? >
