Granularità replicate
In alcuni casi, possono essere presenti più istanze della stessa granularità attiva, ad esempio quando si usa un multi-cluster, e usando OneInstancePerClusterAttribute. JournaledGrain è progettato per supportare istanze replicate con un attrito minimo. Si basa su provider di coerenza dei log per eseguire i protocolli necessari per garantire che tutte le istanze siano d'accordo sulla stessa sequenza di eventi. In particolare, si occupa dei seguenti aspetti:
Versioni coerenti: tutte le versioni dello stato granulare (ad eccezione delle versioni provvisorie) si basano sulla stessa sequenza globale di eventi. In particolare, se due istanze visualizzano lo stesso numero di versione, lo stesso stato viene visualizzato.
Eventi di corsa: più istanze possono generare simultaneamente un evento. Il provider di coerenza risolve questa gara e garantisce che tutti accettino la stessa sequenza.
Notifiche/Reattività: dopo che un evento viene generato in un'istanza di granularità, il provider di coerenza non solo aggiorna l'archiviazione, ma notifica anche tutte le altre istanze di granularità.
Per una discussione generale sulla coerenza, consultare il nostro TechReport e il documento GSP (Global Sequence Protocol).
Eventi condizionali
Gli eventi di gara possono essere problematici se hanno un conflitto, ad esempio non dovrebbero entrambi eseguire il commit per qualche motivo. Ad esempio, quando si ritira del denaro da un conto bancario, due istanze possono determinare in modo indipendente che ci siano fondi sufficienti per un prelievo e rilasciare un evento di prelievo. Ma la combinazione di entrambi gli eventi potrebbe essere eccessiva. Per evitare questo problema, l'API JournaledGrain supporta un metodo RaiseConditionalEvent.
bool success = await RaiseConditionalEvent(
new WithdrawalEvent() { /* ... */ });
Gli eventi condizionali controllano due volte se la versione locale corrisponde alla versione in archiviazione. In caso contrario, significa che la sequenza di eventi è cresciuta nel frattempo, il che significa che questo evento ha perso una gara contro un altro evento. In tal caso, l'evento condizionale non viene accodato al log e RaiseConditionalEvent restituisce false.
Si tratta dell'analogia dell'uso di e-tag con gli aggiornamenti dell'archiviazione condizionale, e fornisce allo stesso modo un meccanismo semplice per evitare il commit di eventi in conflitto.
È possibile e ragionevole usare eventi condizionali e non condizionali per lo stesso livello, ad esempio un DepositEvent e un WithdrawalEvent. I depositi non devono essere condizionali: anche se un DepositEvent perde una gara, non deve essere annullato, ma può comunque essere accodato alla sequenza di eventi globale.
L'attesa dell'attività restituita da RaiseConditionalEvent è sufficiente per confermare l'evento, ovvero non è necessario chiamare anche ConfirmEvents.
Sincronizzazione esplicita
A volte, è consigliabile assicurarsi che una granularità sia completamente in grado di raggiungere la versione più recente. Questa operazione può essere applicata chiamando:
await RefreshNow();
Questa operazione consente di ottenere due risultati:
- Conferma tutti gli eventi non confermati.
- Carica la versione più recente dalla risorsa di archiviazione.
