Executing GraphQL and REST Mutations in a transaction

[severussundar]

Why make this change?

Closes #814

When two update mutations act on the same item, the responses returned back to these mutations are misleading.

Update Mutation that was run:

mutation updateNotebook($id: Int!, $item: UpdateNotebookInput!) {
        updateNotebook(id: $id, item: $item) {
          id
          color
        }
      }

When two graphQL mutations were executed in parallel with the following variables,

{
    "id": 3,
    "item": {
      "color": "cyan"
     }
  }

{
   "id": 3,
   "item": {
      "color": "magenta"
    }
}

the responses for both the mutations were either

{"data":{"updateNotebook":{"id":3,"color":"magenta"}}}

or

{"data":{"updateNotebook":{"id":3,"color":"cyan"}}}

Within the same mutation, the data read back from the database should be the same as that of the updated value.

What is this change?

• For a single graphQL mutation, there are 2 database queries performed. Both these DB queries are run within a single transaction to ensure consistency during concurrent updates.
• Implicit Transactions docs.
• The transaction isolation level is chosen based on the database type and the value chosen is the default isolation level for each database type.
• In the database query constructed for REST upsert scenario, the explicit creation of a transaction using T-SQL statements such as SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;BEGIN TRANSACTION;.. is removed. Since, the entire PerformMutation() block executes within a transactionscope, creation of another transaction with a different isolation level should not be done.
• Integration tests to validate that responses are consistent when there are concurrent requests are added

How was this tested?

• Existing Unit Tests
• Integration Tests
• k6 test suite:

The concurrent test suite written using k6 - link was run in local against each of the database types.

Scenarios covered by the Concurrent Test suite:

Parallel Read Operations on different items
Parallel CRUD Operations on different items
Parallel Update and Read Operations on the same item using GraphQL
Parallel Update and Read Operations on the same item using REST
Parallel Create Operations when the PK is auto-generated
Parallel Create Operations when the PK is not auto-generated
Parallel Delete Operations on the same item

• Jmeter:

Tested concurrent updates with two mutations trying to update the same row
Concurrent graphQL mutation and query updating/reading the same row
Concurrent REST PATCH requests updating the same row
Concurrent REST PATCH and REST GET requests updating/reading the same row
Concurrent graphQL mutation and REST GET acting on the same row.
Performed all the scenarios with 100 threads (50 threads of each request type) to see if there were any occurrences of errors related to transactions when the volume of requests trying to update the same row is high.

[Aniruddh25]

LGTM, thank you for following up on this and all questions we had along the way to better our understanding of transactions!