[SLING-12236] Introduce config option to bypass oak's DataStore deduplication for job properties

• Type: Task
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: Event
• Assignee: Unassigned
• Reporter: Stefan Egli
• Created: 22/Jan/24 12:01
• Updated: 22/Jan/24 12:01

Description

When a sling job is created, its properties are persisted using ResourceHelper.getOrCreateResource. Typically the property values would be primitive types or short Strings and thus be embedded. For larger property values they might be stored as binaries by the underlying DataStore. If for some reason different jobs contain identical property values (i.e. binaries), then they are deduplicated by DataStore. If such identical binaries are concurrently read and written by different Sling instances (as could happen if the job queue is not ORDERED and if identical property binaries are in play in the first place), then DataStore could run into concurrency issues with reading/writing the same binary. That could manifest in sling job eg as a ClassNotFoundException.

This situation could either be avoided by the application ensuring not to have such duplicate job binaries.

Alternatively sling job could consider introducing a job queue configuration that would artificially make binaries unique (by eg prepending a hidden UUID).