Two Phase Commit (2PC)- Distributed Transaction İçindir

Giriş

Distributed Transaction Management için 7 farklı çözüm var. Bunlar şöyle

1. Two-phase commit/XA

2. SAGA

3. TCC (Try, Confirm, Cancel)

4. Local Messaging

5. Transactional Messaging

6. Best-effort Notification

7. Seata-AT

Local Messaging ve Transactional Messaging

Transaction destekleyen ve persistent olan mesaj kuyruğu (message queue) kullanarak gerçekleştirilir.

XA ve JTA İlişkisi

XA standardın ismi. X/Open organizasyonu tarafından yönetiliyor. Açıklaması şöyle

XA is a specification for distributed transactions proposed by the X/Open organization. The XA specification mainly defines the interface between a (global) Transaction Manager (TM) and a (local) Resource Manager (RM). Local databases such as mysql play the RM role in the XA specification.

JTA ise Java gerçekleştirimi. Açıklaması şöyle. 

Two-phase commit(2PC) is a blocking protocol used to guarantee that all the transactions are succeeded or failed together in a distributed transaction.

The XA standard is a specification for the 2PC distributed transactions. JTA includes standard API for XA. JTA-compliant application servers support XA out-of-the-box. But all the resources have to be deployed to a single JTA platform to run 2PC. 

XA Bileşenleri

İki tane bileşen var. 

1. Transaction Manager 

2. Resource Manager

3. Application Program - Bu aslında bileşen sayılmayabilir

 Açıklaması şöyle. 

The XA specification mainly defines the interface between a (global) Transaction Manager (TM) and a (local) Resource Manager (RM). Local databases such as mysql play the RM role in the XA specification.

Two Phase Commit Gerçekleştirimi

İki tane yöntem var.

1. 2PC destekleyen veri tabanı kullanmak

2. Distributed Transaction Manager kullanmak

Açıklaması şöyle. Distributed Transaction Manager olarak Atomikos kullanılabilir

Database Management Systems

Many database management systems, such as Oracle, MySQL, and PostgreSQL, provide support for 2PC out-of-the-box. 

Distributed Transaction Managers

Distributed transaction managers, such as JBoss Transactions, provide support for 2PC and can be used to manage transactions across multiple nodes. When using a distributed transaction manager, you can use 2PC by configuring the transaction manager to use 2PC as the transaction management mechanism.

Hangi Veri Tabanları XA Destekler

 Açıklaması şöyle. 

At present, almost all mainstream databases support XA transactions, including mysql, oracle, sql-server, postgres

Hangi Durumlarda Kullanılır

Strong Consistency (linearizability) gerekiyorsa kullanılır. 

Özellikle

1. Database Replication Varsa

2. Farklı Sistemler Varsa

Açıklaması şöyle

Other than the above database replication scenario for scalability, 2PC is also used when executing transactions between different types of systems such as database servers and message brokers. However, we generally avoid 2PC because of increased lock contention in distributed participants, which leads to poor performance, and hinders scalability. 

Akış Nasıldır?

Şeklen şöyle

Açıklaması şöyle

- Prepare: The participant is asked to check if its data operation can be performed and provide a promise to the transaction coordinator that later on if required, it can commit the operation or rollback. This is done for all the participants. 

- Commit: If all the participants said okay in the prepare phase, each participant is given a commit operation to commit the earlier mentioned operation. At this point, the participant cannot deny the operation, due to the promise given to the transaction coordinator earlier. If any of the participants earlier denied their local data operation due to any reason, the coordinate will send rollback commands to all the participants. 

Örnek

Şeklen şöyle

Voting Aşaması

Eğer tüm sistemler evet cevabını veriyorsa veri bitmiş olarak kabul edilir. Bu aşamaya voting denilir.

Klasik Coordinator Kullanımı
Açıklaması şöyle.

- The Coordinator service asks all the participants if they are ready to commit the transaction. They can reply with a yes or no. Note that if a single service replies with a no ( or a timeout or any other error), the full transaction is automatically canceled.

- If all the participants have answered yes, the Coordinator sends the Commit command to them and waits for the final ack.

Bu yöntemin dezavantajları şöyle.

- First of all, it comes with an intrinsic performance penalty as we're putting all the actors on hold multiple times waiting for an answer. - Secondly, in some cases, it may be possible that other transactions triggered in between are paused until the whole process completes.
- If the Coordinator fails for some reason at the beginning of Phase 2, all the other services are left hanging in a limbo-state.

Coordinator Olmadan Kullanımı
Örneğin kaynağı burası.

1. Two Phase Commit Kullanılmazsa
Bu yöntemin kullanılmadığı şöyle bir senaryo olsun.

Veri tabanına bir işlem yaptıktan sonra commit'lemeden REST çağrısı yapıp çağrı sonucuna göre rollback veya commit yapalım.

1. Eğer REST çağrısı başarılı ancak sonucu bize gelmezse transaction rollback edilir ve veri tutarsız olur
2. Eğer REST çağrısı başarılı ancak bizim commit işlemi başarısız ise veri tutarsız olur

2. İki Transaction Kullanan Two Phase Commit
Daha basit bir yöntem iki transaction kullanmak. Veri önce kendi veri tabanımıza yazılır ancak bitmiş olarak işaretlenmez. Daha sonra REST çağrısı yapılır. Eğer çağrı başarılı ise verimiz bitmiş olarak işaretlenir. Böylece işlem toplam üç transaction'a bölünür. İki tanesi ayrı veri tabanlarında gerçekleşir. Sonuncusu ise voting kabul edilir ve kendi veri tabanımızda gerçekleşir.

Outbox Pattern - Coordinator Olmadan Kullanımı
Açıklaması şöyle. Bu yöntemde tek transaction var ancak veri 2 tabloya yazılıyor.

This pattern provides an effective solution to publish events reliably. The idea of this approach is to have an “Outbox” table in the service’s database. When receiving a request for enrollment, not only an insert into the Student table is done, but a record representing the event is also inserted into the Outbox table. The two database actions are done as part of the same transaction.

An asynchronous process monitors the Outbox table for new entries and if there are any, it publishes the events to the Event Bus. The pattern merely splits the two transactions over different services, increasing reliability.