Azonnali és késleltetett visszaigazolások

Ebben a cikkben megismerheti az azonnali és a késleltetett visszaigazolások közötti különbségeket.

Azonnali megerősítés

Számos alkalmazás esetében biztosítani szeretnénk, hogy az események azonnal megerősítést nyerjenek, hogy a megmaradó verzió ne maradjon le a memóriában lévő aktuális verziótól, és nem kockáztatjuk a legújabb állapot elvesztését, ha a szemcse meghibásodik. Ezt az alábbi szabályok betartásával garantálhatjuk:

1. Győződjön meg arról, hogy az összes RaiseEvent hívást a grain metódus visszatérése előtt használja ConfirmEvents .
2. A szemcsés metódus visszatérése előtt győződjön meg arról, hogy a visszaadott RaiseConditionalEvent feladatok készek.
3. Kerülje ReentrantAttribute vagy AlwaysInterleaveAttribute attribútumok, így egyszerre csak egy szemcsés hívás dolgozható fel.

Ha ezeket a szabályokat követjük, az azt jelenti, hogy egy esemény létrehozása után nem lehet más szemcsés kódot végrehajtani, amíg az eseményt meg nem írjuk a tárolóba. Ezért nem lehet következetlenségeket megfigyelni a memóriában lévő verzió és a tárban lévő verzió között. Bár gyakran pontosan ez az, amit szeretnénk, ennek is vannak lehetséges hátrányai.

Lehetséges hátrányok

• Ha a távoli fürthöz vagy tárolóhoz való csatlakozás ideiglenesen megszakad, akkor a szemcse elérhetetlenné válik: a szemcse gyakorlatilag nem tud kódot végrehajtani, amíg a rendszer elakad az események megerősítésére várva, ami határozatlan ideig tarthat (a naplókonzisztencia protokoll mindaddig újra próbálkozik, amíg a tárolókapcsolat helyre nem áll).

• Ha egyetlen szemcsés példány sok frissítését kezeli, az egyes példányok megerősítése nagyon nem hatékony lehet, például gyenge átviteli sebességet okozhat.

Késleltetett megerősítés

A fent említett helyzetekben a rendelkezésre állás és az átviteli sebesség javítása érdekében a szemcsék az alábbiak egyikét vagy mindkettőt választhatják:

• Hagyja, hogy a szemcsés metódusok megerősítés nélkül emeljenek eseményeket.
• Engedélyezze az újraküldést, hogy a gabona továbbra is feldolgozhassa az új hívásokat, még akkor is, ha a korábbi hívások elakadnak a megerősítésre várva.

Ez azt jelenti, hogy a grain code végrehajtható, miközben egyes események még folyamatban vannak a megerősítés alatt. Az JournaledGrain<TGrainState,TEventBase> API néhány konkrét rendelkezéssel rendelkezik, amelyekkel a fejlesztők pontosan szabályozhatók a jelenleg futó, meg nem erősített események kezelésének módjában.

Az alábbi tulajdonság megvizsgálható annak kiderítéséhez, hogy mely események nincsenek megerősítve:

IEnumerable<EventType> UnconfirmedEvents { get; }

Mivel a tulajdonság által JournaledGrain<TGrainState,TEventBase>.State visszaadott állapot nem tartalmazza a meg nem erősített események hatását, létezik egy másik tulajdonság is.

StateType TentativeState { get; }

Amely egy "feltételes" állapotot ad vissza, amelyet az "Állapot" kifejezésből nyer az összes meg nem erősített esemény alkalmazásával. A feltételes állapot lényegében egy "legjobb tipp", hogy mi lesz a következő megerősített állapot, miután minden meg nem erősített esemény megerősítést kap. Azonban nincs garancia arra, hogy valóban meg fog, mert a szemcsék meghiúsulhatnak, vagy mert az események más események ellen versenyezhetnek, és veszíthetnek, ami miatt törölték őket (ha feltételesek), vagy a vártnál későbbi pozícióban jelennek meg a sorozatban (ha feltétel nélküliek).

Egyidejűségi garanciák

Vegye figyelembe, hogy Orleans a turn-alapú ütemezés (kooperatív egyidejűség) mindig érvényes, még akkor is, ha újrafoglalást vagy késleltetett megerősítést használ. Ez azt jelenti, hogy bár több módszer is folyamatban lehet, csak egy lehet aktívan végrehajtani – minden más várakozik, így soha nem léteznek valódi fajok, amelyeket párhuzamos szálak okoznak.

Vegye figyelembe különösen a következőket:

• A tulajdonságok State, TentativeStateés VersionUnconfirmedEvents a metódus végrehajtása során változhatnak.
• Ezek a változások azonban csak várakozás közben következhetnek be.

Ezek a garanciák feltételezik, hogy a felhasználói kód a tevékenységekre és az aszinkron /várakozásra vonatkozó ajánlott gyakorlaton belül marad (különösen nem használja a szálkészlet-feladatokat, vagy csak olyan kódhoz használja őket, amely nem hívja meg a szemcsés funkciókat, és amelyek megfelelően várnak rá).