Folks, As you know we are developing multi-version concurrency control for Ignite caches, which is essentially new mode for transactional cache with snapshot semantics. One of the most important applications of this mode would be fully transactional SQL The question is how to implement continuous query semantics with MVCC. Several interesting things here.
1) *Event ordering*. Currently we guarantee order of updates for specific key. But for fair transactional mode user may want to get transactional ordering instead of key ordering. If there are several dependent transactions, I may want to receive their updates in order. E.g.: TX1: transfer(A -> B) TX2: transfer(B -> C) TX3: transfer(C -> D) If user receives update on key D (TX3), should we guarantee that he already received updates for all keys in TX1 and TX2? My opinion is that we'd better to leave things as is and guarantee only per-key ordering. Only one reason - implementation complexity. 2) *Initial query*. We implemented it so that user can get some initial data snapshot and then start receiving events. Without MVCC we have no guarantees of visibility. E.g. if key is updated from V1 to V2, it is possible to see V2 in initial query and in event. With MVCC it is now technically possible to query data on certain snapshot and then receive only events happened after this snapshot. So that we never see V2 twice. Do you think we this feature will be interesting for our users? Please share your thoughts. Vladimir.
