Package com.illumon.iris.db.v2.utils

Interface RedirectionIndex

All Known Subinterfaces:
SingleValueRedirectionIndex
All Known Implementing Classes:
ContiguousRedirectionIndexImpl, GroupedRedirectionIndex, IntColumnSourceRedirectionIndex, InverseIndexRedirectionIndexImpl, LongColumnSourceRedirectionIndex, RedirectionIndexLockFreeImpl, StaticSingleValueRedirectionIndexImpl, TickingSingleValueRedirectionIndexImpl, WrappedIndexRedirectionIndexImpl
public interface RedirectionIndex
A RedirectionIndex can be in one of two states: tracking prev values or not. The typical lifecycle looks like this:
  1. A RedirectionIndex is created with an initial map, but not tracking prev values. In this state, get() and getPrev() behave identically; put() and remove() affect current values but do no "prev value" tracking.
  2. Prev value tracking begins when the caller calls startTrackingPrevValues(). Immediately after this call, the data is logically "forked": getPrev() will still refer to the same set of entries as before; this set will be frozen until the end of the generation.
  3. Additionally, a terminal listener will be registered so that the prev map will be updated at the end of the generation.
  4. Meanwhile, get(), put(), and remove() will logically refer to a fork of that map: it will initially have the same entries as prev, but it will diverge over time as the caller does put() and remove() operations.
  5. At the end of the generation (when the TerminalListener runs), the prev set is (logically) discarded, prev gets current, and current becomes the new fork of the map.