Hi Ben
In general, we discourage the use of PUT, anything you can do with PUT you can do also with PATCH. So let's keep the discussion confined to PATCH.
As far as I am aware, the design guidelines TMF630 do not discuss concurrency control, and we could say that this is an implementation decision.
Certainly the contents of the ETag are going to vary per implementation.
If you feel strongly about this, you are welcome to raise a CR (JIRA, if you are a member of the Open API project, or here otherwise).
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: May 22, 2021 14:21
From: Ben Eng
Subject: Concurrency control using HTTP ETag for optimistic locking
Are we missing design guidelines around concurrency control for PUT and PATCH methods to prevent concurrent read-modify-write transactions (i.e., using GET followed by PATCH) from causing lost writes or inconsistencies?
The HTTP ETag mechanism can be used in combination with the If-Match condition on the PUT and PATCH methods to accomplish this. That is, each entity is effectively versioned or timestamped, so that a GET will return an ETag that uniquely identifies that entity's point in history (i.e., version number). The client doing the read-modify-write transaction carries the ETag along and passes it back on the PATCH with the updated entity. The master implementing the PATCH enforces the If-Match condition on the ETag, such that if the entity has already been changed by another transaction, the request is failed because the Etag no longer matches the current state of the entity.
------------------------------
Ben Eng
Oracle Corporation
------------------------------