...
The REST API of the CRUD webservice A&AI Resources is not consistent under concurrent access modification to the same entity (calls using the same ID).
...
- Recommend using max. 1 A&AI REST client.
- PROS: the current state - no effort needed, works "most of the time".
- CONS: not what would be expected of a carrier-grade system by any rational measure
- Having batch jobs scan the database and remove duplicates and corrupted data created due to inconsistencies (this is being used now as problem mitigation)
- PROS: you don't have to deal with the real problem, it is easy because you only target symptoms
- CONS: solution does not work because if data gets corrupted between batch sweeps then the data is unavailable until the batch job runs again. Also adds accidental complexity with batch jobs and their timing.
- Not write data in A&AI Resources directly but use the Champ service (Note: in the future architecturally the Champ project should be the only one accessing the JanusGraph database and A&AI Resources would only forward entity change requests to Champ)
- PROS: Access to JanusGraph database can be properly implemented in Champ without of fear of braking existing functionality
- CONS: Champ seems like a dead initiative and is not going to be finished in the next few years. Correct me if this assessment of Champ is wrong, for example with a concrete finish date.
- Correct the root cause of the inconsistency
- PROS: Webservice would work as expected
- CONS: Changes to core A&AI libraries are needed, potential to break functionality or trigger software regressions. Deep A&AI expertize around data handling needed
...