Stato e persistenza del clamore

4

Sto imparando Clojure per vedere se è qualcosa che posso sfruttare al mio attuale lavoro, e ancora più importante, come posso convincere i miei capi che Clojure ha un 'killer feature' su java che fa valere l'investimento 1 .

La funzione che presumo che la maggior parte degli evangelisti clojuri sarebbe la gestione dello stato e la concorrenza .

L'esempio che vedo spesso nei blog e nei libri è un saldo dell'account che viene aggiornato da più thread. La gestione dello stato di Clojure può sempre garantire in modo pulito che il saldo sia accurato indipendentemente dal numero di thread che leggono e scrivono quel valore.

In pratica, però, un'applicazione non consentirebbe mai un saldo del conto di vivere solo in memoria, dovrebbe essere persistente al di fuori della JVM (probabilmente in un database) per due ragioni, ovviamene ovvie:

  1. Se l'app si interrompe, il database dovrà riflettere accuratamente l'ultimo stato di recupero. Per questo motivo, il database non può essere aggiornato in modo asincrono e tutte le letture dovrebbero essere bloccate fino al completamento dell'aggiornamento del database.
  2. Se altre applicazioni stanno leggendo o manipolare il saldo dell'account (forse perché abbiamo ridimensionato la nostra app su diversi server), tale saldo deve essere tenuto sincronizzato tra tutte le istanze.

La gestione dello stato di Clojure può gestire situazioni come questa in modo elegante? Ad esempio, dato lo scenario 2 sopra, le letture tutte del saldo dell'account dovrebbero prima controllare il database per ottenere il valore, e se il database è bloccato, dovrebbe bloccare fino a quando non è disponibile il valore corretto, no?

È fantastico che Clojure gestisca la concorrenza in-memory in modo molto elegante, ma se quell'eleganza non può essere estesa allo stato esterno, allora guadagno davvero qualcosa?

1 (si noti che cose come espressività, eleganza, ecc. sono raramente considerate caratteristiche killer di mgmt.)

    
posta Roy Truelove 19.07.2012 - 16:43
fonte

3 risposte

2

Lo STM in-memory di Clojure non gestisce direttamente la persistenza duratura (per definizione, è progettato per l'uso in memoria ...)

Tuttavia i principi si applicano ugualmente bene allo storage persistente. Ad esempio, dai un'occhiata a Datomic , che è effettivamente un sistema di gestione di database ACID scalabile basato sulla struttura dei dati di Clojure e sulla filosofia di gestione dello stato.

I principi comuni sono approssimativamente:

  • Strutture dati persistenti immutabili
  • Transizioni di stato gestite da pure funzioni
  • Scalabilità di lettura illimitata (le letture non transazionali non necessitano mai di blocchi)
  • "semantica della transazione" collegabile per adattarsi all'applicazione
  • Separazione dell'identità e dello stato
  • Enfasi sui dati separati dalle funzioni che li elaborano (cioè distinti dal concetto OOP di incapsulare dati e codice)
risposta data 19.07.2012 - 18:50
fonte
1

Come per il classico esempio di trasferimento bancario, puoi ottenere perfettamente la durata: solo send-off un agente all'interno della transazione STM. Poiché le transazioni possono essere ripetute, l'agente viene eseguito solo con l'ultimo tentativo riuscito. L'agente dovrebbe mantenere le informazioni sulla transazione su un DB.

Ritengo che, a volte, l'approccio più comprensibile di RDBMS delle operazioni di mixaggio e persistenza possa essere la soluzione migliore. Quindi mi piacerebbe introdurre un caso di uso comune:

Web server apps often feature a global cache (implemented as some data stucture) in order to avoid DB abuse. Each HTTP request (hence a thread) could read/write to it, so access needs to be concurrency-managed somehow. A locking approach can make this 'cache' actually a bottleneck!

È in questo e in altri scenari simili in cui STM brilla davvero.

    
risposta data 24.07.2012 - 03:13
fonte
-1

In realtà questo sembra un dupe of question on Stack Overflow. Mantenere la domanda anche qui, poiché la domanda sembra più appropriata per questo sito.

Il lungo e il corto di questo è quello per i miei scopi, dal momento che STM non supporta la 'D' in ACID, lo stato di Clojure e la gestione della concorrenza non mi compra nulla. Purtroppo.

    
risposta data 19.07.2012 - 16:47
fonte

Leggi altre domande sui tag