Replikált szemcsék

Előfordulhat, hogy ugyanannak a szemnek több példánya is aktív, például több fürt futtatásakor és a OneInstancePerClusterAttribute. A JournaledGrain úgy lett kialakítva, hogy minimális súrlódással támogassa a replikált példányokat. A naplókonzisztencia-szolgáltatókra támaszkodik a szükséges protokollok futtatásához, hogy minden példány megegyezhessen ugyanazon eseménysorozatban. Különösen a következő szempontokat kezeli:

• Konzisztens verziók: A szemcsés állapot minden verziója (a feltételes verziók kivételével) ugyanazon globális eseménysorozaton alapul. Különösen, ha két példány ugyanazt a verziószámot látja, akkor ugyanazt az állapotot látják.

• Versenyesemények: Egyszerre több példány is létrehozhat egy eseményt. A konzisztenciaszolgáltató megoldja ezt a versenyt, és gondoskodik arról, hogy mindenki egyetértsen ugyanabban a sorrendben.

• Értesítések/Reaktivitás: Miután egy egyszemcsés példányon eseményt emeltek ki, a konzisztenciaszolgáltató nem csak frissíti a tárterületet, hanem az összes többi gabonapéldányt is értesíti.

A konzisztencia általános ismertetéséhez tekintse meg a TechReportot és a GSP-tanulmányt (Global Sequence Protocol).

Feltételes események

A versenyesemények akkor lehetnek problémásak, ha ütközésük van, vagyis valamilyen okból nem kell mindkettőt véglegesíteni. Ha például pénzt vesz fel egy bankszámláról, két példány egymástól függetlenül megállapíthatja, hogy elegendő pénz áll rendelkezésre a kifizetéshez, és kibocsáthat egy kifizetési eseményt. A két esemény kombinációja azonban túlterjedhet. Ennek elkerülése érdekében az API támogatja a JournaledGrain metódust RaiseConditionalEvent .

bool success = await RaiseConditionalEvent(
    new WithdrawalEvent() { /* ... */ });

A feltételes események kétszer ellenőrzik, hogy a helyi verzió megegyezik-e a tárban lévő verzióval. Ha nem, az azt jelenti, hogy az eseménysorozat időközben megnőtt, ami azt jelenti, hogy ez az esemény egy versenyt vesztett egy másik esemény ellen. Ebben az esetben a rendszer nem fűzi hozzá a feltételes eseményt a naplóhoz, és RaiseConditionalEvent hamis értéket ad vissza.

Ez az e-címkék feltételes tárolási frissítésekkel való használatának analógija, és hasonlóképpen egy egyszerű mechanizmust biztosít az ütköző események véglegesítésének elkerülésére.

Lehetséges és ésszerű mind a feltételes, mind a feltétel nélküli eseményeket használni ugyanahhoz a szemhez, mint például az a DepositEvent és a WithdrawalEvent. A betéteknek nem kell feltételesnek lenniük: még akkor sem, ha egy DepositEvent verseny veszít, nem kell lemondani, de továbbra is hozzáfűzhetők a globális eseménysorozathoz.

A visszaadott RaiseConditionalEvent feladatra való várakozás elegendő az esemény megerősítéséhez, azaz nem szükséges a hívás ConfirmEventsis.

Explicit szinkronizálás

Néha kívánatos gondoskodni arról, hogy egy gabona teljes mértékben felzárkózott a legújabb verzióhoz. Ezt a következő hívással lehet kikényszeríteni:

await RefreshNow();

Ez két dolgot tesz:

1. Megerősíti az összes meg nem erősített eseményt.
2. Betölti a legújabb verziót a tárolóból.