FHIR Specification:
- https://www.hl7.org/fhir/http.html#ccreate
The conditional create interaction allows a client to create a new resource only if some equivalent resource does not already exist on the server. The client defines what equivalence means in this case by supplying a FHIR search query using an HL7 defined extension header "If-None-Exist" as shown:
If-None-Exist: [search parameters]
- https://www.hl7.org/fhir/http.html#cond-update
The conditional update interaction allows a client to update an existing resource based on some identification criteria, rather than by logical id. To accomplish this, the client issues a PUT as shown:
PUT [base]/[type]?[search parameters]
For example:
PUT path/Observation?identifier=http://my-lab-system|123
The current implementation performs a FHIR search to retrieve a set of resources matching the search query parameters. Although the search and subsequent insert occur in the same transaction, the default transaction isolation level is READ COMMITTED which means that a concurrent user might create a matching resource after the search has been computed but before this request performs the create.
If transactions from the two competing threads overlap, consistency with respect to resource versioning is guaranteed because the create/update logic locks the resource record (if one exists) in the database. The second transaction will be blocked until the first transaction commits.
Although the integrity of the resource history is guaranteed, currently there is no way to tell the server to skip the creation altogether if a match is found. Even if a client were to perform a GET first and then only submit the PUT if the resource didn't exist, there is still a time-window within which another thread or system could create the resource. There is therefore no way to prevent an additional version being created with conditional create/update requests running in a concurrent environment.
See #2050 for a possible solution.
FHIR Specification:
For example:
The current implementation performs a FHIR search to retrieve a set of resources matching the search query parameters. Although the search and subsequent insert occur in the same transaction, the default transaction isolation level is READ COMMITTED which means that a concurrent user might create a matching resource after the search has been computed but before this request performs the create.
If transactions from the two competing threads overlap, consistency with respect to resource versioning is guaranteed because the create/update logic locks the resource record (if one exists) in the database. The second transaction will be blocked until the first transaction commits.
Although the integrity of the resource history is guaranteed, currently there is no way to tell the server to skip the creation altogether if a match is found. Even if a client were to perform a GET first and then only submit the PUT if the resource didn't exist, there is still a time-window within which another thread or system could create the resource. There is therefore no way to prevent an additional version being created with conditional create/update requests running in a concurrent environment.
See #2050 for a possible solution.