Questa domanda non è così filosofica come potrebbe suggerire il titolo. Considerare il seguente approccio alla persistenza:Nell'attore persistente di Akka, sta creando un attore bambino considerato un effetto collaterale o la creazione di uno stato?
I comandi per eseguire operazioni provengono da vari client. Rappresento sia le operazioni che i clienti come attori persistenti. Lo stato del Cliente è l'ultimoOsservazione da passare. Lo stato dell'operazione è praticamente un FSM dei progressi dell'operazione (è in effetti una Saga, in quanto deve quindi raggiungere altri sistemi esterni a ActorSystem per spostarsi attraverso i suoi stati).
Un attore di ricezione riceve il comando di operazione, che contiene l'id del client e l'id di operazione. L'attore Reception crea o recupera l'attore Client e lo inoltra il comando. L'attore Client legge e convalida il comando operazione, lo mantiene, crea un evento OperationReceived, aggiorna il proprio stato con questo id operativo. Ora è necessario creare un nuovo attore Operazione per gestire la nuova operazione di lunga durata. Ma qui è dove mi perdo e tutti i begli esempi nella documentazione e nei vari blog non aiutano. La maggior parte dei commentatori afferma che PersistentActor converte i comandi in eventi e quindi aggiorna il loro stato. Possono anche avere effetti collaterali a condizione che non vengano richiamati durante la riproduzione. Così ho due aree di confusione:
- è la creazione di un attore Operazione in questo contesto, equivalente a la creazione dello stato, o che svolgono un effetto collaterale? Non sembra un effetto collaterale, ma allo stesso tempo non sta cambiando il suo stato, ma sta causando un cambiamento di stato in un nuovo bambino.
- Devo costruire un comando da inviare al nuovo attore Operazione o lo inoltro semplicemente all'evento OperationReceived?
Se partecipo alla mia ipotesi che la creazione di un attore secondario non è un effetto collaterale, significa che devo anche creare il bambino durante la riproduzione. Ciò a sua volta causerebbe il recupero dello stato del bambino.
Spero che la domanda di fondo sia chiara. Sento che è una domanda generale, ma il modo migliore per formularlo è dare un esempio specifico.
Edit: Riflettendoci, credo che la creazione di un attore persistente da un altro è un atto di creazione dello stato, sia pure in outsourcing. Ciò significa che l'evento che attiva la creazione attiverà quella creazione su una riproduzione successiva (che porterà al recupero dello stato persistente del bambino). Questo mi fa pensare che passare l'evento (piuttosto che un comando di wrapping) potrebbe essere la cosa più pulita da fare in quanto è possibile applicare lo stesso evento per aggiornare lo stato sia in genitore che in figlio. Non dovrebbe esserci bisogno di persistere l'evento mentre entra nel bambino - è già stato mantenuto nel genitore e verrà riprodotto.
Aggiungerò la modifica sopra riportata come risposta poiché la domanda stessa sembra avere un numero di voti positivi. – Brendan
Hai un'idea su come combinare questa architettura con un diario di istantanee? Dato che lo stato degli attori figli non si riflette nell'attore genitore, come andresti su questo? – thwiegan
@thwiegan scusa per il ritardo nel rispondere - la tua domanda (anche fatta sotto per flare) è molto pertinente. Data la realtà delle istantanee, penso sia inevitabile affermare che ogni istanza di attore persistente può essere responsabile solo del proprio stato. Le mie preoccupazioni riguardavano la questione di "cosa causerà il recupero di un attore secondario dalla persistenza quando il genitore viene recuperato?" Penso che la risposta sia che non ce n'è bisogno. Un attore secondario verrà recuperato solo quando viene fatto riferimento direttamente. Sembra essere un errore di categoria per cercare di trattare il grafico degli attori come una struttura di dati a sé stante. – Brendan