AWS aurora-dsql documentation change
Summary
Restructured concurrency control documentation with added details about optimistic concurrency control (OCC), transaction conflict resolution mechanisms, and performance optimization guidelines
Security assessment
The changes focus on concurrency control mechanics (lock-free architecture, conflict resolution) and performance best practices. While they mention transaction integrity and error handling, there is no evidence of addressing security vulnerabilities or introducing security-specific features. The serialization errors and retry logic discussed relate to concurrency management rather than security protections.
Diff
diff --git a/aurora-dsql/latest/userguide/working-with-concurrency-control.md b/aurora-dsql/latest/userguide/working-with-concurrency-control.md index 863a458f5..e6a073fb9 100644 --- a//aurora-dsql/latest/userguide/working-with-concurrency-control.md +++ b//aurora-dsql/latest/userguide/working-with-concurrency-control.md @@ -4,0 +5,2 @@ +Transaction conflictsGuidelines for optimizing transaction performance + @@ -7 +9,3 @@ Amazon Aurora DSQL is provided as a Preview service. To learn more, see [Betas a -# Aurora DSQL concurrency control +# Concurrency control in Aurora DSQL + + _Concurrency_ allows multiple sessions to access and modify data simultaneously without compromising data integrity and consistency. Aurora DSQL provides [ PostgreSQL compatibility](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html) while implementing modern concurrency control mechanisms. It maintains full ACID compliance through snapshot isolation, ensuring data consistency and reliability. @@ -9 +13 @@ Amazon Aurora DSQL is provided as a Preview service. To learn more, see [Betas a -Aurora DSQL provides [PostgreSQL compatibility](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html). When you use repeatable read operations in PostgreSQL, they work the same as ACID transactions with snapshot isolation in Aurora DSQL. One key difference is that Aurora DSQL uses lock-free concurrency control instead of PostgreSQL's lock-based approach. This approach means the following: +A key advantage of Aurora DSQL is its lock-free architecture, which eliminates common database performance bottlenecks. Aurora DSQL prevents slow transactions from blocking other operations and eliminates the risk of deadlocks. This approach makes Aurora DSQL particularly valuable for high-throughput applications where performance and scalability are critical. @@ -11 +15 @@ Aurora DSQL provides [PostgreSQL compatibility](https://docs.aws.amazon.com/auro - * Slow transactions don't block other transactions. +## Transaction conflicts @@ -13 +17 @@ Aurora DSQL provides [PostgreSQL compatibility](https://docs.aws.amazon.com/auro - * Transactional deadlocks can't occur. +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: @@ -14,0 +19 @@ Aurora DSQL provides [PostgreSQL compatibility](https://docs.aws.amazon.com/auro + * The transaction with the earliest commit time is processed by Aurora DSQL. @@ -15,0 +21 @@ Aurora DSQL provides [PostgreSQL compatibility](https://docs.aws.amazon.com/auro + * Conflicting transactions receive a PostgreSQL serialization error, indicating the need to be retried. @@ -18 +23,0 @@ Aurora DSQL provides [PostgreSQL compatibility](https://docs.aws.amazon.com/auro -Aurora DSQL uses optimistic concurrency control (OCC), which evaluates transactions at commit time rather than establishing locks on changed rows or tables. This approach assumes that your applications minimize conflicts, making object locking unnecessary in most cases. @@ -20 +24,0 @@ Aurora DSQL uses optimistic concurrency control (OCC), which evaluates transacti -When conflicts occur, as when multiple concurrent transactions update the same row, Aurora DSQL processes the transaction with the earliest commit time. All other conflicting transactions return a PostgreSQL serialization error. To handle these conflicts, implement abort and retry logic in your applications. While this logic executes more frequently with OCC than with lock-based systems, it follows the same pattern you would use for PostgreSQL lock timeouts or deadlocks. For best results, design your applications to be idempotent, retrying transactions automatically when possible. @@ -22 +26 @@ When conflicts occur, as when multiple concurrent transactions update the same r -To optimize relational workload performance with any concurrency control scheme, do the following: +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. @@ -24 +28 @@ To optimize relational workload performance with any concurrency control scheme, - * Avoid high contention on single keys or small key ranges (hot keys). +## Guidelines for optimizing transaction performance @@ -26 +30 @@ To optimize relational workload performance with any concurrency control scheme, - * Design your schema to spread update operations across your cluster key range. +To optimize performance, minimize high contention on single keys or small key ranges. To achieve this goal, design your schema to spread updates over your cluster key range by using the following guidelines: @@ -28 +32 @@ To optimize relational workload performance with any concurrency control scheme, - * Consider using random primary keys. + * Choose a random primary key for your tables. @@ -30 +34 @@ To optimize relational workload performance with any concurrency control scheme, - * Avoid patterns that increase contention on single keys as business growth increases updates. + * Avoid patterns that increase contention on single keys. This approach ensures optimal performance even as transaction volume grows. @@ -43 +47 @@ Connections -Data definition language +DDL and distributed transactions