Transazioni con attori

Si afferma correttamente che le transazioni e il blocco sono necessari per gestire lo stato mutabile condiviso. E anche che in un sistema di attori non esiste uno stato mutabile condiviso. Quindi sembra che tu abbia già risposto alla tua domanda da solo.

I see that it can be necessary for some actor to lock one or more other actor(s) to send them several updates such that no other actor interferes.

Non ti seguo abbastanza qui. Perché dovresti progettare un sistema come questo?

This is called "shared state", "locking" and transaction.

No, penso che questa conclusione non sia corretta. Poiché lo stato è incapsulato all'interno di un attore e può essere modificato solo inviando messaggi a questo attore, questo stato non è considerato condiviso - è di proprietà dell'attore, non lo condivide con nessuno. L'aggiornamento di questo stato inviando messaggi non implicherebbe il blocco o una transazione. La modifica concomitante è esclusa dall'elaborazione sequenziale del messaggio dell'attore, che a volte viene definita "illusione a thread singolo".

I do not understand how Actor Model saves us from them and revolutionazes anything. Alternatively, consider a simple actor model: multiple processor actors + memory actor.

Ancora una volta, questo sembra essere un design atipico. Che cosa dovrebbe essere un "attore della memoria"? Perché dovresti separare l'elaborazione dallo stato?

Ho la sensazione che tu stia tentando di trasferire una soluzione esistente a un'architettura radicalmente diversa, che è destinata a fallire. Piuttosto che cercare di far comportare gli attori in un modo a cui sei abituato, dovresti accettare che avrà bisogno di un approccio diverso. Potresti trovare utile leggere qualcosa sulla progettazione di sistemi basati su attori, ad es. " Modelli di progettazione reattiva ".

Il modello di attore non risolve magicamente tutti i problemi. Rende solo una tale astrazione della programmazione concorrente che aiuta a ragionare sulle soluzioni.

Ci sono due aspetti principali del modello di attore, che lo rendono molto utile nella mia pratica.

Innanzitutto, quando l'IT risolve un problema aziendale, ciò che fa è tradurre in modo efficace i processi e le regole aziendali nel linguaggio dei computer. Ma i processi aziendali sono costruiti attorno alle persone in alcune strutture organizzative. E gli attori modellano bene queste strutture con la supervisione, non condividendo lo stato interno e il monitoraggio. Quindi, i processi di business sono costruiti da persone per le persone - quindi, assumono un ragionamento da parte delle persone e di solito sono abbastanza comprensibili. Quindi, la modellazione con gli attori si allinea abbastanza bene con i problemi aziendali e si adatta al cervello umano.

In secondo luogo, gli attori sono MOLTO utili nella modellazione di timeout, attività rischiose, cortocircuiti, tentativi esponenziali e così via. Ancora una volta, la supervisione e il monitoraggio aiutano.

Per quanto riguarda le transazioni, il primo aspetto menzionato le riguarda. Le transazioni possono essere modellate con gli attori così come sono usate nel mondo umano. Pensa a Problema di due generali . La comunicazione degli attori è asincrona. Se usi gli attori, vivi e basta. Quindi, hai almeno una volta la consegna (se aggiungi la conferma) o al massimo una volta (l'impostazione predefinita di Akka). Quindi, scegli ciò che si adatta al tuo problema e modella le transazioni con esso. Anche se probabilmente finirai con più linee di codice, ma i vantaggi sono astrazioni e scalabilità più semplici e pronte all'uso.

Devo anche aggiungere che tutte le qualità menzionate del modello di attore lo rendono ideale per il design basato sul dominio basato sull'architettura esagonale, con o senza Event-Sourcing. Il mio uso di Akka è proprio questo. E DDD è piuttosto preoccupato per le transazioni di dominio.