Maybe I haven’t explained my situation well, but it is more I am trying to gain time / budget with a quick fix rather than going through a hard re-factor
UI = User Interface, App
XP = API layer created for the UI which is an aggregation or mutation layer (like GraphQL, but custom)
DS = Our Data Services, Microservices with version optimistic concurrency control implemented (same as you explained)
UI calls XP (GET), and XP internally aggregate GET different DS (you get 3 different version of 3 differnt entities)
UI calls XP (PUT), and XP only needs to call 1 PUT API which orchestrates (saga-pattern) over 2 DS of the previous obtained.
In the perfect world, the XP GET will provide in the XP PUT the version number associated to every entity if the JSON format was correctly aggregated, structured according to the entities aggegated.
However, due to our current situation (which is out of my hands). The APIs designed for the XP are using a JSON structure format which makes difficult to understand the separation between entities.
What I was trying to avoid is to re-factor around 350 REST operation JSONs and the UI app to accomodate the version attribute properly to the entity mapped obtained in the DS.
Out of curiosity, I thought that if it would be possible that <= is used instead of = as it will solve my problem easier as I can hide the version attribute in my XP layer, and just send in any DTO entity back what was the timestamp during retrieaval. This timestamp is one generated by the XP (GET), not one of the multiple that can come from the DS.
Any other providers, can consume the DS layer with concurrency control without issues, as they will get JSON and update it with the same structure. However, our UI API + UI will be affected to accomodate this.
To summary the question is.
Is it possible to tune the @Version comparison behaviour?
If not, I think I will not have any other choice that re-factor the XP layer (JSON structures, so I can map each version entity to the corresponding one)