Transaction handling in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the result of this transaction sequence?

Consider a GraphQL API that supports transactions with the following operations:

mutation {
  startTransaction {
    transactionId
  }
}

mutation {
  updateUser(id: 1, name: "Alice") {
    id
    name
  }
}

mutation {
  commitTransaction(transactionId: "tx123") {
    success
  }
}

Assuming the updateUser mutation is executed within the transaction started, what will be the final name of the user with id 1 after commit?

A The user's name will be updated to "Alice" after commit.

B The user's name will remain unchanged because commitTransaction does not apply changes.

C The user's name will be "Alice" immediately after updateUser, even before commit.

D The transaction will fail and the user's name will be rolled back to the previous value.

💡 Hint

Think about what commitTransaction does in a transaction context.

In transaction handling, changes made inside a transaction are only visible after the transaction is committed. So the user's name changes to "Alice" after commitTransaction succeeds.

📝 Syntax

intermediate

Identify the syntax error in this transaction mutation

Which of the following GraphQL mutations correctly starts a transaction?

A mutation { startTransaction: transactionId }

B mutation startTransaction { transactionId }

C mutation { startTransaction(transactionId) }

D mutation { startTransaction { transactionId } }

💡 Hint

Recall the correct syntax for GraphQL mutations and field selection.

Option D uses the correct syntax: mutation keyword, braces, and selection set. Other options have syntax errors like missing braces or invalid argument usage.

❓ optimization

advanced

Optimize transaction usage for multiple updates

You want to update multiple user records atomically using GraphQL transactions. Which approach is best to minimize transaction overhead?

A Start a transaction, update each user one by one inside it, then commit once at the end.

B Start and commit a separate transaction for each user update.

C Update all users without transactions to improve speed.

D Start a transaction, update one user, commit, then start a new transaction for the next user.

💡 Hint

Think about how transactions reduce overhead when grouping operations.

Starting one transaction and committing once after all updates reduces overhead and ensures atomicity. Multiple transactions increase overhead and risk partial updates.

🔧 Debug

advanced

Why does this transaction rollback unexpectedly?

Given this sequence:

mutation { startTransaction { transactionId } }
mutation { updateUser(id: 2, name: "Bob") { id name } }
mutation { rollbackTransaction(transactionId: "tx999") { success } }

The updateUser mutation is executed, but the rollbackTransaction uses a wrong transactionId. What happens to the update?

A The updateUser mutation fails because the transaction is invalid.

B The updateUser change is rolled back despite the wrong transactionId.

C The updateUser change remains uncommitted and visible only inside the transaction.

D The updateUser change is committed automatically because rollback failed.

💡 Hint

Consider what happens if rollbackTransaction targets a non-existent transaction.

If rollbackTransaction fails due to wrong transactionId, the transaction remains active or committed depending on implementation. Usually, changes are committed or remain visible after mutation if rollback fails.

🧠 Conceptual

expert

What is the isolation level effect in GraphQL transactions?

In a GraphQL API supporting transactions, what does the isolation level control?

A The order in which mutations are executed inside a transaction.

B How visible uncommitted changes are to other transactions.

C The maximum time a transaction can stay open before auto-commit.

D The number of concurrent transactions allowed per user.

💡 Hint

Think about what isolation means in database transactions.

Isolation level defines how and when changes made in one transaction become visible to others, preventing issues like dirty reads or phantom reads.