C100DEV Drivers, Tools, Transactions, and Search Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Retry the insert operation within the same transaction without aborting, hoping the duplicate key error resolves.

  Why it's wrong here

  Retrying the same insert within the same transaction will fail again because the duplicate key error is due to a constraint violation, not a transient issue. The transaction is in an error state and cannot continue. The only correct action is to abort the transaction and then decide whether to retry the whole transaction after addressing the root cause.

• ✗

  Call session.commitTransaction() to commit the successful update and ignore the failed insert.

  Why it's wrong here

  Committing the transaction after an operation has failed would persist the update to 'orders' but not the insert to 'audit', violating the atomicity of the transaction. The transaction is designed to be all-or-nothing; committing a partially failed transaction is not allowed and would likely throw an error. This approach would lead to inconsistent data.

• ✓

  Call session.abortTransaction() to roll back the update, then retry the entire transaction if appropriate.

  Why this is correct

  When an operation within a transaction fails, the transaction must be aborted to undo any changes made before the failure. Calling abortTransaction() ensures the update to 'orders' is rolled back, maintaining atomicity. After aborting, the developer can decide whether to retry the transaction, possibly after handling the duplicate key error (e.g., by checking if the audit record already exists). This is the correct way to handle errors in a transaction.

• ✗

  Call session.endSession() to close the session and automatically roll back the transaction.

  Why it's wrong here

  While ending a session will eventually clean up resources, it does not explicitly abort the transaction. The transaction may remain open until the session times out, and the update might still be applied if the transaction is later committed by another operation. It is not a reliable way to roll back; explicit abortTransaction() is required for deterministic behavior.