OrmLite'ta yeniden deneme politikası ve okuma replikaları

ServiceStack v10.4, OrmLite'a deadlock, throttling ve failover gibi geçici veritabanı hatalarını tek bir yapılandırma satırıyla güvenli biçimde yeniden deneme özelliği ekliyor. Ayrıca okuma sorgularını bir read replica'ya yönlendirmek ve salt okunur bağlantılarda yanlışlıkla yapılan yazmaları geliştirme aşamasında yakalamak mümkün hale geliyor. .NET veri katmanı kuran geliştiriciler için doğrudan pratik değer taşıyor.

Kilit noktalar

• OrmLiteConfig.RetryPolicy = OrmLiteRetry.Exponential(maxRetries: 3) ile geçici hatalar otomatik yeniden denenir
• RunInTransaction bloğu hata durumunda geri alınıp tamamen yeniden çalıştırılır; tek ifade yeniden denenmez
• Bağlantı koptuğunda yalnızca okuma ifadeleri tekrar edilir, çünkü yazma iki kez uygulanmış olabilir
• Transaction içindeki e-posta, ödeme gibi yan etkileri commit sonrasına taşıyın
• OpenReadOnlyDbConnection() replika yoksa birincil veritabanına düşer ve salt okunur bağlantı yazmayı reddeder
• ReadYourWritesFor varsayılan 5 saniyedir; replika gecikmesinde yazılan veriyi görmek için kullanılır

ServiceStack v10.4 ile OrmLite, deadlock, serileştirme hatası, throttling ve bağlantı kopması gibi geçici veritabanı hatalarını kendi içinde yeniden deniyor. OrmLiteConfig.RetryPolicy ile üstel geri çekilmeli bir politika tanımlanıyor; RunInTransaction içindeki işlem, hata alındığında tamamen geri alınıp yeniden çalıştırılıyor. Yeniden denemenin güvenli olup olmadığı ayrım yapılarak belirleniyor: veritabanı uygulanmadığını doğrularsa her ifade tekrar edilebilir, bağlantı koptuysa yalnızca okumalar tekrar edilir.

Ayrıca read replica desteği geliyor. AddReadReplica ile kayıt edilen replikaya OpenReadOnlyDbConnection üzerinden okuma yapılabiliyor; replika yoksa bağlantı birincil veritabanına düşüyor. Salt okunur bağlantılar yazma işlemlerini reddediyor, böylece geliştirmede fark edilmeyen replika hataları production'a sızmadan yakalanıyor. Kodu yazmadan önce yeniden deneme kapsamını ve transaction içindeki e-posta gibi yan etkileri orijinal dokümandan kontrol etmek faydalı olur.

Gerçek dünyada kullanımı

• Yüksek eşzamanlılıklı bir ödeme veya bakiye transferi servisinde deadlock'ların kullanıcıya hata olarak dönmesini engellemek
• Raporlama ağırlıklı bir ASP.NET Core uygulamasında okuma yükünü PostgreSQL standby replikasına taşımak
• Bulut veritabanında throttling alan bir SaaS API'sinde geçici hataları üstel bekleme ile yeniden denemek

Neden önemli

Geçici veritabanı hataları için el yapımı retry döngüleri yazmadan, hangi işlemlerin güvenle tekrarlanabileceğini OrmLite'a bırakabilirsiniz. Okuma replikası kullanırken salt okunur bağlantı sayesinde replika hataları geliştirme sırasında görülür.

Benzer haberler

• ASP.NET Core Web API'de sık yapılan 6 hata ve yerine kullanılacak desenlerDVDEV Community: #aspnetcore23 Eki
• MCP Sunucularında Ölçekte Rate Limiting ve Kaynak YönetişimiDVDEV Community: #aspnetcore1 gün önce
• NebulaGraph'a .NET'ten idempotent toplu yükleme: VID ile çoğaltma sorunuDVDEV Community: #csharp3 gün önce