Optimistic offline lock pattern

Acest deisgn pattern, optimistic offline lock este o tehnica de a manageui acces-ul concurent la datele comune intr-un sistem distribuit.
Acest pattern se bazeaza pe presupunerea ca conflictele intre update-uri vor fi rare, iar majoritatea update-urilor pot fi rezolvate fara conflicte.

Ideea din spatele acestui pattern este aceea ca fiecare client al aplicatiei mentine o copie a datelor comune si isi poate updata copia independent de ceilalti clienti. Cand un client vrea sa updateze datele comune prima data verifica daca s-a modificat ceva de catre alt client in intervalul de timp din care el si-a luat versiunea lui de date. Daca nu s-a modificat nimic, update-ul este aplicat si modificarea este propagata catre ceilalti clienti. Totusi, daca datele au fost modificate de alt client intre timp, update-ul nu este aplicat, iar clientul primeste un mesaj de conflict. Clientul poate alege fie sa suprascrie datele modificate de ceilalti clienti sau sa uneasca modificarea lui cu a altor clienti.

Acest pattern este des folosit in scenariile in care exista o problema de durata de transmisiune a datelor prin retea sau exista posibilitatea ca un client sa devina offline, de exemplu o aplicatie de mobil care se poate deconecta de la internet. Pentru ca se poate lucra cu copia datelor salvata local, clientul isi poate continua treaba chiar daca nu mai are semnal/internet.

Totusi, este important de mentionat ca acest pattern nu este potrivit pentru un sistem in care conflictele de date sunt frecvente sau consistenta datelor este critica.

Mai jos am sa incerc sa dau un exemplu in PHP pentru modul de functionare al acestui pattern:

1. Cand un client isi ia datele de la server, primeste si salveaza si un timestamp ce indica timpul ultimei modificari pe acest set de date.

$data = file_get_contents('https://invata-programare.ro/datele_de_care_am_nevoie.json');
$timestamp = file_get_contents('https://invata-programare.ro/ultima_modificare_a_datelor.txt');

2. Salvez datele local

file_put_contents('datele_de_care_am_nevoie.json', $data);
file_put_contents('ultima_modificare_a_datelor.txt', $timestamp);

3. Imi fac update-ul dorit pe copia mea a datelor

$localData = json_decode(file_get_contents('datele_de_care_am_nevoie.json'));
$localData->informatiaMea = 'noua valoare pentru aceasta informatie';
$localData = json_encode($localData);

4. Verific timestamp-ul local cu cel de pe server:

$localTimestamp = file_get_contents('ultima_modificare_a_datelor.txt');
$serverTimestamp = file_get_contents('https://invata-programare.ro/ultima_modificare_a_datelor.txt');

5. Daca datele de modificare coincid pot trimite update-ul catre server:

if ($localTimestamp == $serverTimestamp) {

	$response = file_get_contents('https://invata-programare.ro/update.php', false, stream_context_create([
        'http' => [
            'method' => 'POST',
            'header' => 'Content-type: application/json',
            'content' => $localData,
        ],
    ]));
    if ($response == 'conflict') {
        // am un conflict, trebuie sa il rezolv
    }
}

Atentie aici, daca server-ul ne indica un conflict trebuie sa il tratam, fie suprascriem modificarile de pe server fie unim modificarile.

Ce trebuie mentionat din nou este faptul ca acest pattern porneste de la ideea ca o sa avem putine conflicte si putem sa le rezolvam rapid/usor.