Parallel Writing to Condition Record Sets

Available from version 15.0

Previously, the system supported only sequential writing to the Condition Record Item Keys (CRCI1 - CRCI12). To improve performance, parallel writing to Condition Record Sets has been implemented.

To enable parallel writing, a Condition Record Splicing job has been developed. This job writes the Condition Record Item Keys to the distinct Condition Record Sets (CRCS). Each job is dedicated to writing to one specific Condition Record Set. (For more information see Condition Records Splicing Options). This enhancement ensures data access safety for concurrent processes. Parallel jobs can execute simultaneously across the different Condition Record Sets. However, if the multiple Condition Record logics need to write to the same Condition Record Set (i.e., share the same concurrent key, representing the Condition Record Set), the corresponding Splicing jobs will be executed serially, one after the other.

This approach also ensures the consistency of splicing operations. By allowing only one running splicing job per Condition Record Set, Condition Records are spliced correctly.

Specifically, the Condition Record Processing job executes Condition Record logics, generating the Condition Record Processings. Subsequently, the Condition Record Splicing job performs splicing operations and writes these Condition Record Processings into the appropriate Condition Record Sets, creating the Condition Record Item Keys (CRCI1 - CRCI12).

Additionally, please note that, specifically for loaddata, Condition Record Splicing jobs are created directly, without involving Processing Jobs or executing Condition Record logic. In this case, loaddata loads Condition Record Processing directly. For more information see Condition Records Splicing Options.

Running CRCS Jobs as Lightweight Jobs

Available from version 17.1

Condition Record Splicing jobs only update database objects and do not execute any heavy Groovy logic, so they typically complete in a few seconds even for a Condition Record Set with around 100 items. By default, these jobs always run as normal (non-lightweight) background jobs, which means each one incurs the standard job startup overhead (heartbeat check and pod start) — often 30+ seconds — regardless of how little work the job actually had to do.

CRCS jobs can, however, be run as lightweight jobs, skipping that startup overhead when the job is small enough.

As noted above, jobs sharing the same concurrency key (i.e., writing to the same Condition Record Set) are always executed serially, never in parallel. Initially, this meant that each job in such a queue still had to wait for a separate background-worker kick cycle before starting, even once the preceding job had already finished — so making jobs lightweight mainly reduced resource usage per job without meaningfully reducing the total time to process a whole queue. This has since been refined: once a job finishes, the next queued job with the same concurrency key now starts immediately, without waiting for the next kick cycle. As a result, the lightweight-job savings (skipping pod-start and heartbeat overhead) now compound across a queue of jobs targeting the same Condition Record Set, significantly reducing total processing time for large batches.

Configuration

This behavior is controlled by the following Application property:

This works the same way as the existing numberOfItemsConsideredLightweight property used for calculable objects (Live Price Grid, Price List, Calculation Grid, etc.), but applies specifically to Condition Record Splicing jobs.