Anında ve gecikmeli onaylar
Bu makalede, anında ve gecikmeli onaylar arasındaki farkları öğreneceksiniz.
Anında onay
Birçok uygulama için, kalıcı sürümün bellekteki geçerli sürümün gerisinde kalmaması ve tahılın başarısız olması durumunda en son durumu kaybetme riskinin olmaması için olayların hemen onaylandığından emin olmak istiyoruz. Bu kuralları uygulayarak bunu garanti edebiliriz:
- Grain yöntemi döndürmeden önce kullanarak ConfirmEvents tüm RaiseEvent çağrıları onaylayın.
- Grain yöntemi döndürmeden önce tamamlanan görevlerin döndürdüğünden RaiseConditionalEvent emin olun.
- AlwaysInterleaveAttribute Veya özniteliklerinden kaçınınReentrantAttribute; bu nedenle aynı anda yalnızca bir taneli çağrı işlenebilir.
Bu kurallara uyarsak, bir olay oluşturulduktan sonra olay depolama alanına yazılana kadar başka bir tanecik kodu yürütülemez. Bu nedenle, bellekteki sürümle depolamadaki sürüm arasındaki tutarsızlıkları gözlemlemek mümkün değildir. Bu genellikle tam olarak istediğimiz şey olsa da, bazı olası dezavantajları da vardır.
Olası dezavantajlar
Uzak bir kümeye veya depolamaya bağlantı geçici olarak kesilirse, dilim kullanılamaz hale gelir: etkili bir şekilde, hub'lar olayları onaylamak için beklerken herhangi bir kodu yürütemez ve bu da süresiz bir süre alabilir (günlük tutarlılığı protokolü, depolama bağlantısı geri yüklenene kadar yeniden denemeye devam eder).
Tek bir örnek için çok fazla güncelleştirme işlenirken, bunları birer birer onaylamak çok verimsiz hale gelebilir, örneğin, düşük aktarım hızına neden olabilir.
Gecikmeli onay
Yukarıda belirtilen durumlarda kullanılabilirliği ve aktarım hızını geliştirmek için, tanecikler aşağıdakilerden birini veya ikisini birden yapmayı seçebilir:
- Tahıl yöntemlerinin onay beklemeden olayları tetiklesine izin verin.
- Yeniden girişe izin verin, böylece önceki aramalar onay beklerken takılmış olsa bile tahıl yeni çağrıları işlemeye devam edebilir.
Başka bir deyişle, bazı olaylar hala onaylanma sürecindeyken ayrıntılı kod yürütülebilir. API, JournaledGrain<TGrainState,TEventBase> geliştiricilere şu anda uçuşta olan doğrulanmamış olaylarla nasıl başa çıkabilecekleri konusunda kesin denetim sağlamak için bazı belirli hükümlere sahiptir.
Şu anda doğrulanmamış olan olayları bulmak için aşağıdaki özellik incelenebilir:
IEnumerable<EventType> UnconfirmedEvents { get; }
Ayrıca, özelliği tarafından JournaledGrain<TGrainState,TEventBase>.State döndürülen durum doğrulanmamış olayların etkisini içermediğinden, alternatif bir özellik vardır
StateType TentativeState { get; }
Doğrulanmamış tüm olaylar uygulanarak "State" öğesinden alınan "belirsiz" bir durum döndürür. Kesin olmayan durum, doğrulanmamış tüm olaylar onaylandıktan sonra bir sonraki onaylanan durum olma olasılığına ilişkin bir "en iyi tahmindir". Ancak, tahıl başarısız olabileceğinden veya olaylar diğer olaylara karşı yarışıp kaybedebileceğinden, iptal edilmesine (koşulluysalar) veya beklenenden daha sonraki bir sırada görünmesine (koşulsuzsa) neden olabileceğinden, bunun gerçekten de garantisi yoktur.
Eşzamanlılık garantileri
Yeniden giriş veya gecikmeli onay kullanılırken bile sıra tabanlı zamanlama (işbirliği eşzamanlılığı) garantilerinin her zaman geçerli olduğunu Orleans unutmayın. Bu, birkaç yöntem devam ediyor olsa bile, yalnızca birinin etkin bir şekilde yürütülebileceği anlamına gelir; diğer tüm yöntemler bir bekleme sırasında takılır, dolayısıyla paralel iş parçacıklarının neden olduğu gerçek yarışlar asla yoktur.
Özellikle şunları unutmayın:
- , TentativeState, Versionve UnconfirmedEvents özellikleriState, bir yöntemin yürütülmesi sırasında değişebilir.
- Ancak bu tür değişiklikler yalnızca bir bekleme sırasında takılırken gerçekleşebilir.
Bu garantiler, kullanıcı kodunun görevler ve zaman uyumsuz/await ile ilgili önerilen uygulama içinde kaldığını varsayar (özellikle iş parçacığı havuzu görevlerini kullanmaz veya bunları yalnızca taneli işlevselliği çağırmayan ve düzgün bir şekilde beklenen kod için kullanır).
