Package com.qfs.multiversion

Interface IEpochManagementPolicy

All Known Implementing Classes:
ADefaultEpochPolicy, KeepAllEpochPolicy, KeepLastEpochPolicy
public interface IEpochManagementPolicy
Policy of global epochs and memory management. Note that only one policy object will be used for the histories of all components.
Author:
ActiveViam

  • Method Details

    • onCommit

      void onCommit(IEpoch epoch, IEpochHistory history)
      Executed after each commit on a component.

      This method can be called in parallel with different histories (for different components), and in parallel with invoke(IEpochManager).

      Parameters:
      epoch - the epoch of the commit
      history - the epoch history of the component

    • invoke

      void invoke(IEpochManager epochManager)
      Executes periodic tasks.

      In this method, epochs can be released, marked or unmarked.

      This method can be called in parallel with onCommit.

      Parameters:
      epochManager - the epoch manager of global application

    • getInvokeInterval

      long getInvokeInterval()
      Gets time interval (in ms) between two invocations of invoke(com.qfs.multiversion.IEpochManager).
      Returns:
      time (in ms) between invoke calls, if negative, no periodical invocation will be used

    • discardAtCommit

      boolean discardAtCommit()
      Tells whether or not a discard task should be executed asynchronously after each commit. The task does not block the commit.

      Default to false.

      Returns:
      true if discard should be called asynchronously after each commit, false otherwise

    • discardTriggeredByGc

      boolean discardTriggeredByGc()
      Tells whether or not the discard should be triggered by the garbage collection of the version objects.

      Default to true.

      Returns:
      true if discard should be called when some versions objects are found to be garbage collected, false otherwise

    • getCompressionThreadCount

      default int getCompressionThreadCount()
      Returns the maximum number of threads that can perform compression work.

      Increasing this limit means that the compaction will run faster, at the cost of using more threads, potentially blocking transactions.

      Note that it is possible to add a dynamic limit here, for example by checking ForkJoinPool.getActiveThreadCount().

      This limit is per IVersionHistory. So there can be this many threads compacting the datastore and this many threads for each of the cubes. To avoid that, you can override getCompressionThreadPool() to run the compression in a different thread pool altogether.

      Returns:
      the maximum number of threads that can perform compression work

    • getCompressionThreadPool

      default IThreadPoolSelector getCompressionThreadPool()
      Returns the maximum number of threads that can perform compression work.
      Returns:
      the maximum number of threads that can perform compression work