Cosa devo fare quando il blocco ottimistico non funziona?

Ho questo scenario seguente:

1. Un utente invia una richiesta GET a /projects/1e riceve un ETag .
2. L'utente invia una richiesta PUT a /projects/1con ETag dal passaggio 1.
3. L'utente invia un'altra richiesta PUT a /projects/1con ETag dal passaggio 1.

Normalmente, la seconda richiesta PUT riceverebbe una risposta 412, poiché l'ETag è ormai obsoleto: la prima richiesta PUT ha modificato la risorsa, quindi l'ETag non corrisponde più.

Ma cosa succede se le due richieste PUT vengono inviate contemporaneamente (o esattamente una dopo l'altra)? La prima richiesta PUT non ha il tempo di elaborare e aggiornare la risorsa prima dell'arrivo di PUT # 2, che fa sì che PUT # 2 sovrascriva PUT # 1. L'intero punto del blocco ottimistico è che ciò non accada ...

Il meccanismo ETag specifica solo il protocollo di comunicazione per il blocco ottimistico. È responsabilità del servizio applicativo implementare il meccanismo per rilevare gli aggiornamenti simultanei per imporre il blocco ottimistico.

In un'applicazione tipica che utilizza un database, di solito lo si fa aprendo una transazione durante l'elaborazione di una richiesta PUT. Normalmente leggeresti lo stato esistente del database all'interno di quella transazione (per ottenere un blocco di lettura), verificheresti la validità di Etag e sovrascriveresti i dati (in un modo che provocherebbe un conflitto di scrittura in caso di transazioni concorrenti incompatibili), quindi impegnarsi. Se imposti correttamente la transazione, uno dei commit dovrebbe fallire perché entrambi cercheranno di aggiornare gli stessi dati contemporaneamente. Sarai quindi in grado di utilizzare questo errore di transazione per restituire 412 o ritentare la richiesta, se ha senso per l'applicazione.

Devi eseguire atomicamente la seguente coppia:

• verifica della validità del tag (ovvero aggiornato)
• aggiornamento della risorsa (che include l'aggiornamento del relativo tag)

Altri lo chiamano transazione - ma fondamentalmente, l'esecuzione atomica di queste due operazioni è ciò che impedisce a uno di sovrascrivere l'altro per errore di tempistica; senza questo hai una condizione di gara, come stai notando.

Questo è ancora considerato un blocco ottimistico, se si guarda al quadro generale: che la risorsa stessa non è bloccata dalla lettura iniziale (GET) da qualsiasi Utente o qualsiasi Utente che sta guardando i dati, sia con l'intenzione di aggiornare o meno.

È necessario un certo comportamento atomico, ma ciò accade all'interno di una singola richiesta (PUT) anziché tentare di mantenere un blocco su più interazioni di rete; questo è un blocco ottimistico: l'oggetto non è bloccato da GET ma può ancora essere aggiornato in modo sicuro da PUT.

Esistono anche molti modi per ottenere l'esecuzione atomica di queste due operazioni: bloccare la risorsa non è l'unica opzione; ad esempio, un thread leggero o un blocco oggetti possono essere sufficienti e dipendono dall'architettura dell'applicazione e dal contesto di esecuzione.

Sta allo sviluppatore dell'applicazione controllare effettivamente l'E-Tag e fornire quella logica. Non è magico che il web server fa per te perché sa solo come calcolare le E-Tagintestazioni per il contenuto statico. Quindi prendiamo il tuo scenario sopra e analizziamo come dovrebbe avvenire l'interazione.

GET /projects/1

Il server riceve la richiesta, determina l'E-Tag per questa versione del record, restituendola con il contenuto effettivo.

200 - OK
E-Tag: "412"
Content-Type: application/json
{modified: false}

Poiché il client ha ora il valore E-Tag, può includere quello con la PUTrichiesta:

PUT /projects/1
If-Match: "412"
Content-Type: application/json
{modified: true}

A questo punto l'applicazione deve effettuare le seguenti operazioni:

• Verifica che l'E-Tag sia ancora corretto: "412" == "412"?
• In tal caso, effettua l'aggiornamento e calcola un nuovo E-Tag

Invia la risposta di successo.

204 No Content
E-Tag: "543"

Se arriva un'altra richiesta e tenta di eseguire una PUTsimile alla richiesta precedente, la seconda volta che il codice del server lo valuta, l'utente è tenuto a fornire il messaggio di errore.

• Verifica che l'E-Tag sia ancora corretto: "412"! = "543"

In caso di errore, inviare la risposta all'errore.

412 Precondition Failed

Questo è il codice che devi effettivamente scrivere. L'etichetta elettronica può infatti essere qualsiasi testo (entro i limiti definiti nelle specifiche HTTP). Non deve essere un numero. Può anche essere un valore di hash.

A complemento delle altre risposte, posterò una delle migliori citazioni nella documentazione di ZeroMQ che descrive fedelmente il problema di fondo:

Per realizzare programmi MT assolutamente perfetti (e intendo letteralmente), non abbiamo bisogno di mutex, blocchi o qualsiasi altra forma di comunicazione inter-thread eccetto i messaggi inviati attraverso i socket ZeroMQ.

Per "programmi MT perfetti" intendo un codice facile da scrivere e da capire, che funziona con lo stesso approccio progettuale in qualsiasi linguaggio di programmazione e su qualsiasi sistema operativo e che si adatta a qualsiasi numero di CPU con zero stati di attesa e nessun punto di rendimenti decrescenti.

Se hai passato anni a imparare i trucchi per far funzionare il tuo codice MT, per non parlare rapidamente, con blocchi, semafori e sezioni critiche, rimarrai disgustato quando ti rendi conto che non è tutto per niente. Se c'è una lezione che abbiamo imparato da oltre 30 anni di programmazione concorrente, è: semplicemente non condividere lo stato. È come due ubriaconi che cercano di condividere una birra. Non importa se sono buoni amici. Prima o poi entreranno in una rissa. E più ubriachi aggiungi al tavolo, più si combattono a vicenda sulla birra. La tragica maggioranza delle applicazioni MT sembrano combattimenti da bar ubriachi.