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?
