...
Jira link:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Spike Status: IN PROGRESS COMPLETED
Objective: To enable the R/W split of the DB for mod-source-record-manager to have improvements in performance
Background
RMB-348 (RMB v35.0.0) introduced the ability to direct the read and write calls to the respective database node, the reader or writer (if the database is configured in such a way). The separation of read and write queries brings performance improvements and scalability as the Write node is freed up to do more writing while the read node is busy making retrievals. Read-only code in RMB has been updated to communicate to the Read node directly. To take advantage of the read/write split, mod-source-record-manager replaced the read-only code that calls the existing RMB read methods (which could handle both read and writes) with one of the new RMB read-only methods that exclusively communicates to the read node (MODSOURMAN-883).
Problem Statement
Update of the JobExecution to assign the JobProfile (write query) and the request to process a record (reads assigned JobProfile for JobExecution) come separately (sequence of requests is described in data-import-workflow). In case Read instance is not synchronizing fast enough, some single record operations and importing via API could fail. See details in MODSOURMAN-909 and MODSOURMAN-906. To prevent such errors R/W split for mod-source-record-manager is disabled for Nolana (R3 2022) and Orchid (R1 2023) releases.
...
Implemented changes required to enable R/W split for mod-source-record-manager.
Option 1 - Selected
Use regular RMB read method (which can handle both read and writes) for request to get JobExecution by id. This way the request will go to the write version of the DB, which has the necessary information.
Pros
- Simple and quick to implement
- Easy to back-port to Nolana and Orchid
- Low risk of regression
- No reason to expect significant impact on performance
...