Using readless increments in concurrent transactions causes conflicts

Also see this github issue: https://github.com/cdap-guides/cdap-cube-guide/issues/21

It would make sense to enable that for Cubes. In fact I am wondering whether that should be the default.

However, the Cube's FactTable performs both increment() and put(), and I am not sure whether it is safe to disable conflict detection. It might be ok, because even with conflict detection, if concurrent processes emit gauges, they would overwrite each other values.

https://github.com/caskdata/cdap/blob/develop/cdap-data-fabric/src/main/java/co/cask/cdap/data2/dataset2/lib/timeseries/FactTable.java#L145

This needs a little more thinking, but I definitely vote for adding a section to the documentation, both for Table and Cube (and perhaps TimeseriesTable, too?).

Would it also be appropriate to add the option to enable readless increments to the Cube documentation?

See https://issues.cask.co/browse/CDAP-2560 for a discussion. I do think that we should improve the documentation here: http://docs.cdap.io/cdap/current/en/developers-manual/building-blocks/datasets/table.html#increment, and recommend that conflict detection should also be configured as NONE.

The reason why readless increments still participate in conflict detection - if conflict detection is turned on for the table - is that a readless increment, even though it does not conflict with other readless increments, does conflict with other operations, such as delete or put.

Also, tables with readless increment enabled do allow other operations (possibly on columns/rows other than the ones participating in readless increments) that may conflict with each other. That is why we do not turn off conflict detection automatically.