Bilgi işlemin ilk günlerinde dağıtılmış işlemlere gerek yoktu. Uygulama sayısı arttıkça, verilerin senkronizasyonu önemli bir konu haline geldi. Şirketler, veri akışı açısından senkronize sistemleri sürdürmek için çok para ödedi. Sonuç olarak, XA(eXtended Architecture) olarak adlandırılan 2 aşamalı taahhüt protokolü ortaya çıktı. Bu protokol, global işlem işleme için ACID benzeri özellikler sağlar. Bu makale boyunca, XA işlemlerinin detaylarını ve XA İşlemlerinin Spring çerçevesinde kullanımını açıklamaya çalışacağım.

2 aşamalı taahhüt protokolü, dağıtılmış sistemler için atomik bir taahhüt protokolüdür. Bu protokol adından da anlaşılacağı gibi iki aşamadan oluşmaktadır. İlki, işlem yöneticisinin tüm işlem kaynaklarını taahhüt etmek veya iptal etmek için koordine ettiği taahhüt-istek aşamasıdır. Taahhüt aşamasında, işlem yöneticisi, her bir işlem kaynağının oylarına göre taahhüt veya iptal ederek işlemi sonlandırmaya karar verir. Daha sonra 2PC protokolünün uygulama detaylarına geçeceğiz.

2PC aracılığıyla Java + .NET Birlikte Çalışabilirliği ile ilgili kaynaklar için buraya bakın.

XA işlemleri, her XA kaynağı için bir genel işlem kimliğine ve yerel işlem kimliğine(xid) ihtiyaç duyar. Her XA Kaynağı, start(xid) yöntemiyle XA Yöneticisine kaydedilir. Bu yöntem, XA Kaynağının işleme dahil olduğunu söyler (işlemlere hazır olun). Bundan sonra, hazırla(xid) yöntemi çağrılarak 2PC protokolünün ilk aşaması gerçekleştirilir. Bu yöntem, XA Kaynağından Tamam veya İPTAL oyu ister. XA Kaynaklarının her birinden oy aldıktan sonra, XA Yöneticisi tüm XA Kaynakları OK gönderirse bir taahhüt(xid) işlemi yürütmeye karar verir veya bir XA Kaynağı İPTAL gönderirse bir geri alma(xid) yürütmeye karar verir. Son olarak, işlemin tamamlandığını bildiren XA Kaynaklarının her biri için end(xid) yöntemi çağrılır. Daha iyi anlamak için şekle bakın. XA işlem uygulamasında bir arka plan oluştururken, daha sonra daha derine ineceğiz ve bu komutu bu komutu bu komutları ve olası çözümleri yazarak göreceğiz.


Ağ kaybı, makinenin kapanması ve bazı yönetici hataları nedeniyle arızalar herhangi bir zamanda meydana gelebilir. XA işleminde bu arızaları oluştukları aşamalara göre kategorize edeceğiz. İlk başarısızlık aşaması, protokol başlatılmadan öncedir. Bu, sistemin geri almasına veya herhangi bir işlem yapmasına gerek olmayan basit bir arızadır. Sadece o an için işlemi yapmıyoruz. İkinci olarak bu komutu bu komutu yazın, bu hata komutu, zaman aşımı ilkeleri kullanılarak geri almalarla kolayca işlenen hazırlık (taahhüt-istek) aşamasında meydana gelebilir. Son fakat en az değil, tamamlanmamış geri dönüşler ve zincirdeki herhangi bir sorun nedeniyle oluşabilecek tamamlama aşaması hatalarıdır. Yukarıdaki tüm bu durumlarda, işlem yöneticisi sorunu gidermeye çalışır. Daha sonra işlem yöneticisinin başarısızlıkların üstesinden nasıl gelmeye çalıştığını göreceğiz.

Kurtarma sırasında, işlem yöneticisi her XA kaynağının kurtarma yöntemini çağırır. XA Resources, günlükleri izler ve en son durumunu yeniden oluşturmaya çalışır. İşlem Yöneticisi gerekli geri alma işlemlerini çağırır ve görev tamamlanır. Bu süreç mutlu bir yol gibi görünebilir, ancak günlüklerin bozulma gibi sorunlu olduğu birçok istisnai durum vardır. Bu tür durumlarda, işlem yöneticisi sorunu çözmek için bazı buluşsal yöntemleri takip eder. Ayrıca, kurtarma işlemi, uygulamadan önce işlem günlüklerini yazdığınız önden yazma günlüklerine bağlıdır. Performans konularında bu günlükler kendi formatlarında yazılır (herhangi bir serileştirme kullanılmaz) ve sistem mümkünse bunları daha iyi gruplamalıdır. Daha sonra Spring framework tarafından XA işlem desteği olan eğlenceli kısma geçiyoruz.

Spring framework, web ve bağımsız uygulamalar geliştirmek için kapsamlı bir ortam sağlar. Sağladığı diğer yardımcı programlar gibi, XA işlemleri de Spring tarafından desteklenmektedir. Ancak bu destek yerel bir uygulama değildir ve hazırda bekletme, web kapsayıcısı veya XA İşlem Yönetimi sağlayan bir çerçeve gerektirir. Spring, işlem yönetimi araçları sağlayan ve ayrıntıları gizleyen JtaTransactionManager’a sahiptir. Bu sayede aynı anda güncellenen birden fazla DataSource için işlem yönetimine sahip olabiliriz. XA İşlem Yönetimini kullanmaya gelince, XA işlemleri için hazırda bekletme ve web kapsayıcıları desteği iyi belgelenmiştir, bahsetmeye gerek yok. Ancak, XA işlemleri sağlayan bir çerçeve ile çalışmak kafa karıştırıcı olabilir. Bu yüzden Bitronix İşlem Yöneticisini tanıtarak bu yazıya devam edeceğim.

Bitronix, işlem yönetimi için iyi bir destek sağlarken kolayca yapılandırılır. Tek başına uygulamalarda yaygın olarak kullanılmamaktadır ancak bağımsız uygulama için aşağıdaki konfigürasyonu vermeye çalışacağım.

Artık aşağıdaki gibi yapılandırılabilen birden fazla veri kaynağımız olabilir. Her veri kaynağının benzersiz olan bir uniqueName özelliği olmalıdır. Aşağıdaki konfigürasyon Oracle içindir, diğer veritabanları farklı konfigürasyonlara sahip olabilir. Diğer detaylar için Bitronix web sitesini inceleyebilirsiniz.

Özetle XA İşlemlerinin ne olduğunu, temel protokolleri ve Spring ile Bitronix İşlem Yönetimi entegrasyonunu bağımsız bir uygulamada açıklamaya çalıştık. Genişletmek için XA İşlemleri, aynı anda farklı veri kaynaklarının değiştirilmesini sağlar. Ayrıca, XA İşlemleri, web kapsayıcıları veya hazırda bekletme benzeri çerçeveler tarafından desteklenir. Yine de, işlem yönetimini, işlem yöneticisini yapılandırmamız gereken bağımsız bir uygulamaya entegre etmemiz gerekebilir. Sonuç olarak, XA işlemi, birden fazla veri kaynağı üzerinde tutarlı işlemler sağlar ve şirketler bunları kullanır.
Bu makalenin, XA İşlemleri Nasıl Yapılır (2 Aşamalı Taahhüt): Basit Bir Kılavuz konusunda size yardımcı olduğunu umuyoruz. Başka sorularınız varsa, sorularınızı yanıtlamaktan memnuniyet duyarız; lütfen aşağıdaki bölümden bizimle iletişime geçin. paylaşmayı unutma signalfix.net aileniz ve arkadaşlarınızla!