AWS aurora-dsql documentation change
Summary
Updated documentation to rename 'Transaction conflicts' section to 'Concurrency control responses' and added detailed explanations of OCC error codes OC000 (data conflict) and OC001 (schema conflict) with specific error messages and handling guidance.
Security assessment
This change provides clearer documentation about concurrency control mechanisms and error handling in Aurora DSQL. It describes how the system handles data and schema conflicts through optimistic concurrency control, which is a reliability and performance feature rather than a security feature. No evidence of addressing security vulnerabilities or weaknesses.
Diff
diff --git a/aurora-dsql/latest/userguide/working-with-concurrency-control.md b/aurora-dsql/latest/userguide/working-with-concurrency-control.md index 3cc029a13..8f6705e0d 100644 --- a//aurora-dsql/latest/userguide/working-with-concurrency-control.md +++ b//aurora-dsql/latest/userguide/working-with-concurrency-control.md @@ -7 +7 @@ -Transaction conflictsGuidelines for optimizing transaction performance +Concurrency control responsesGuidelines for optimizing transaction performance @@ -15 +15 @@ A key advantage of Aurora DSQL is its lock-free architecture, which eliminates c -## Transaction conflicts +## Concurrency control responses @@ -17 +17 @@ A key advantage of Aurora DSQL is its lock-free architecture, which eliminates c -Aurora DSQL uses optimistic concurrency control (OCC), which works differently from traditional lock-based systems. Instead of using locks, OCC evaluates conflicts at commit time. When multiple transactions conflict while updating the same row, Aurora DSQL manages transactions as follows: +Aurora DSQL uses optimistic concurrency control (OCC), which works differently from traditional lock-based systems. Instead of using locks, OCC evaluates conflicts at commit time. When Aurora DSQL detects a conflict, it returns a PostgreSQL serialization failure with SQLSTATE code `40001`. The response message includes an OCC code that identifies the type of conflict: @@ -19 +19 @@ Aurora DSQL uses optimistic concurrency control (OCC), which works differently f - * The transaction with the earliest commit time is processed by Aurora DSQL. +**OC000 — Data conflict** @@ -21 +20,0 @@ Aurora DSQL uses optimistic concurrency control (OCC), which works differently f - * Conflicting transactions receive a PostgreSQL serialization error, indicating the need to be retried. @@ -22,0 +22 @@ Aurora DSQL uses optimistic concurrency control (OCC), which works differently f +Two transactions attempted to modify the same row. The transaction with the earliest commit time succeeds, and the conflicting transaction receives the OC000 response: @@ -24,0 +25 @@ Aurora DSQL uses optimistic concurrency control (OCC), which works differently f + ERROR: mutation conflicts with another transaction, retry as needed (OC000) (SQLSTATE 40001) @@ -26 +27,11 @@ Aurora DSQL uses optimistic concurrency control (OCC), which works differently f -Design your applications to implement retry logic to handle conflicts. The ideal design pattern is idempotent, enabling transaction retry as a first recourse whenever possible. The recommended logic is similar to the abort and retry logic in a standard PostgreSQL lock timeout or deadlock situation. However, OCC requires your applications to exercise this logic more frequently. +**OC001 — Schema conflict** + + +The session's cached schema catalog is out of date. When Aurora DSQL detects that the catalog version has changed since the session loaded its cache, and the transaction can't safely rebase to the current version, the transaction receives the OC001 response: + + + ERROR: schema has been updated by another transaction, please retry: (OC001) (SQLSTATE 40001) + +Any operation that modifies the schema catalog can cause an OC001 response, including DDL statements such as `CREATE TABLE` and `ALTER TABLE`, as well as `GRANT` and `REVOKE` statements. For more information, see [DDL and distributed transactions in Aurora DSQL](./working-with-ddl.html). + +Design your applications to implement retry logic to handle these responses. The ideal design pattern is idempotent, enabling transaction retry as a first recourse whenever possible. The recommended logic is similar to the abort and retry logic in a standard PostgreSQL lock timeout or deadlock situation. However, OCC requires your applications to exercise this logic more frequently.