Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Controllo della concorrenza in Aurora DSQL
La concorrenza consente a più sessioni di accedere e modificare i dati contemporaneamente senza compromettere l’integrità e la coerenza dei dati. Aurora DSQL offre la [compatibilità con PostgreSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html) implementando al contempo un meccanismo di controllo della concorrenza moderno e senza blocchi. Mantiene la piena conformità ACID attraverso l’isolamento degli snapshot, garantendo la coerenza e l’affidabilità dei dati.
Un vantaggio chiave di Aurora DSQL è la sua architettura priva di blocchi, che elimina i comuni colli di bottiglia nelle prestazioni del database. Aurora DSQL impedisce che le transazioni lente blocchino altre operazioni ed elimina il rischio di deadlock. Questo approccio rende Aurora DSQL particolarmente utile per applicazioni ad alto throughput, in cui le prestazioni e la scalabilità sono fondamentali.
## Risposte di controllo della concorrenza
Aurora DSQL utilizza il controllo ottimistico della concorrenza (OCC), che funziona in modo diverso dai tradizionali sistemi basati su blocchi. Invece di utilizzare i blocchi, OCC valuta i conflitti al momento del commit. Quando Aurora DSQL rileva un conflitto, restituisce un errore di serializzazione PostgreSQL con codice SQLSTATE. `40001` Il messaggio di risposta include un codice OCC che identifica il tipo di conflitto:
**OC000 — Conflitto di dati**
Due transazioni hanno tentato di modificare la stessa riga. La transazione con il primo tempo di commit ha esito positivo e la transazione in conflitto riceve la risposta OC000:
```
ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001)
```
**OC001 — Conflitto di schema**
Il catalogo degli schemi memorizzati nella cache della sessione non è aggiornato. Quando Aurora DSQL rileva che la versione del catalogo è cambiata da quando la sessione ha caricato la cache e che la transazione non può essere ripristinata in modo sicuro alla versione corrente, la transazione riceve la risposta OC001:
```
ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)
```
Qualsiasi operazione che modifica il catalogo degli schemi può causare una risposta OC001, incluse istruzioni DDL come `CREATE TABLE` and e and. `ALTER TABLE` `GRANT` `REVOKE` Per ulteriori informazioni, consulta [DDL e transazioni distribuite in Aurora DSQL](working-with-ddl.md).
Progettate le applicazioni in modo da implementare la logica dei tentativi per gestire queste risposte. Il modello di progettazione ideale è idempotente e consente di ripetere la transazione come primo rimedio, quando possibile. La logica consigliata è simile alla logica abort and retry in una situazione di timeout o deadlock di PostgreSQL standard. Tuttavia, OCC richiede che le applicazioni applichino questa logica più frequentemente.
## Linee guida per l’ottimizzazione delle prestazioni delle transazioni
Per ottimizzare le prestazioni, è opportuno ridurre al minimo contese elevate su chiavi singole o intervalli di chiavi ridotti. Per raggiungere questo obiettivo, progetta lo schema in modo da distribuire gli aggiornamenti sull’intervallo di chiavi del cluster utilizzando le seguenti linee guida:
+ Scegli una chiave primaria casuale per le tabelle.
+ Evita i modelli che fanno aumentare la contesa sulle singole chiavi. Questo approccio garantisce prestazioni ottimali anche con l’aumento del volume delle transazioni.