Memahami Komponen TPS

Setiap sistem pemrosesan transaksi (TPS) yang menggunakan Kernel Transaction Manager (KTM) dan Common Log File System (CLFS) harus berisi komponen penting berikut:

  • Manajer transaksi (KTM)

    KTM melacak status setiap transaksi dan mengoordinasikan operasi pemulihan setelah crash sistem.

  • Satu atau beberapa manajer sumber daya

    Resource manager, yang Anda berikan, mengelola data yang terkait dengan setiap transaksi.

  • Satu atau beberapa aliran log CLFS

    Manajer transaksi dan manajer sumber daya menggunakan aliran log CLFS untuk merekam informasi yang dapat digunakan untuk menerapkan, mengembalikan, atau memulihkan transaksi.

  • Satu atau beberapa klien transaksi

    Biasanya, setiap klien transaksional TPS Anda dapat membuat transaksi, melakukan operasi pada data dalam konteks transaksi, lalu memulai operasi penerapan atau pembatalan untuk transaksi.

Topik ini memperkenalkan Anda ke TPS sederhana dengan satu manajer sumber daya, TPS yang lebih kompleks yang berisi beberapa manajer sumber daya, dan beberapa skenario TPS lainnya.

Bagian Menggunakan KTM memberikan informasi terperinci tentang cara menggunakan KTM untuk membuat komponen TPS.

TPS sederhana

TPS sederhana mungkin terdiri dari KTM, satu manajer sumber daya, dan CLFS. Klien transaksi dapat berkomunikasi dengan manajer sumber daya oleh antarmuka yang disediakan manajer sumber daya.

Misalnya, Anda ingin membuat sistem manajemen database. Anda ingin klien sistem Anda mengakses database dengan membuka handel ke objek database, melakukan operasi baca dan tulis pada objek, lalu menutup handel objek.

Sekarang misalkan Anda ingin serangkaian operasi baca dan tulis terjadi secara atomik sehingga pengguna lain dari sistem hanya melihat hasil akhir. Anda dapat mencapai tujuan tersebut dengan merancang TPS yang memungkinkan klien mengikat serangkaian operasi database ke transaksi.

Sistem Anda harus menyertakan manajer sumber daya yang mengelola data dalam database sebagai respons terhadap permintaan baca dan tulis dari klien. Manajer sumber daya ini dapat mengekspor antarmuka pemrograman aplikasi (API) yang memungkinkan klien untuk mengaitkan transaksi dengan serangkaian operasi baca dan tulis.

Ketika manajer sumber daya Anda dimuat, manajer sumber daya harus mendaftarkan dirinya dengan KTM dengan memanggil ZwCreateTransactionManager dan ZwCreateResourceManager. Kemudian, resource manager dapat berpartisipasi dalam transaksi.

Anda mungkin ingin manajer sumber daya Anda mendukung sekumpulan fungsi yang memungkinkan klien membuat objek data, membaca dan menulis data yang terkait dengan objek data, dan menutup objek data. Pseudocode berikut menunjukkan contoh urutan kode dari klien.

CreateDataObject (IN TransactionID, OUT DataHandle);
ReadData (IN DataHandle, OUT Data);
WriteData (IN DataHandle, IN Data);
WriteData (IN DataHandle, IN Data);
WriteData (IN DataHandle, IN Data);
CloseDataObject (IN DataHandle);

Sebelum klien dapat memanggil rutinitas CreateDataObject manajer sumber daya Anda, klien harus membuat objek transaksi dengan memanggil rutinitas ZwCreateTransaction KTM dan mendapatkan pengidentifikasi objek transaksi dengan memanggil ZwQueryInformationTransaction.

Saat klien memanggil rutinitas CreateDataObject manajer sumber daya Anda, klien meneruskan pengidentifikasi objek transaksi ke manajer sumber daya. Manajer sumber daya dapat memanggil ZwOpenTransaction untuk mendapatkan handel ke objek transaksi, dan kemudian dapat memanggil ZwCreateEnlistment untuk mendaftarkan partisipasinya dalam transaksi.

Pada titik ini, klien dapat mulai melakukan operasi pada objek data. Karena klien memberikan pengidentifikasi transaksi saat membuat objek data, manajer sumber daya dapat menetapkan semua operasi baca dan tulis ke transaksi.

Manajer sumber daya Anda harus merekam semua hasil operasi data yang ditentukan klien tanpa membuat hasilnya permanen. Biasanya, resource manager menggunakan CLFS untuk merekam hasil operasi dalam aliran log transaksi.

Ketika klien telah selesai memanggil manajer sumber daya untuk melakukan operasi transaksional, klien memanggil rutinitas ZwCommitTransaction KTM. Pada titik ini, KTM memberi tahu manajer sumber daya bahwa itu harus membuat operasi permanen. Manajer sumber daya kemudian memindahkan hasil operasi dari aliran log ke media penyimpanan permanen data. Terakhir, manajer sumber daya memanggil ZwCommitComplete untuk memberi tahu KTM bahwa operasi penerapan selesai.

Apa yang terjadi jika resource manager Anda melaporkan kesalahan untuk salah satu panggilan klien ke ReadData atau WriteData? Klien dapat memanggil ZwRollbackTransaction untuk mengembalikan transaksi. Sebagai hasil dari panggilan itu, KTM memberi tahu manajer sumber daya bahwa KTM harus memulihkan data ke keadaan semula. Kemudian, klien dapat membuat transaksi baru untuk operasi yang sama, atau dapat memilih untuk tidak melanjutkan.

Pseudocode berikut menunjukkan contoh urutan operasi transaksi klien yang lebih rinci.

    ZwCreateTransaction (&TransactionHandle, ...);
    ZwQueryInformationTransaction (TransactionHandle, ...);
    CreateDataObject (TransactionID, &DataHandle);
    Status = ReadData (DataHandle, &Data1);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data2);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data3);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data4);
    if (Status == Error) goto ErrorRollback;
    ZwCommitTransaction (TransactionHandle, ...);
    goto Leave;
ErrorRollback:
    ZwRollbackTransaction (TransactionHandle, ...);
Leave:
    ZwClose (TransactionHandle);
    return;

Apa yang terjadi jika sistem crash setelah transaksi dibuat tetapi sebelum dilakukan atau digulung balik? Setiap kali manajer sumber daya Anda dimuat, manajer sumber daya harus memanggil ZwRecoverTransactionManager dan ZwRecoverResourceManager. Memanggil ZwRecoverTransactionManager menyebabkan KTM membuka aliran lognya dan membaca riwayat transaksi. Memanggil ZwRecoverResourceManager menyebabkan KTM memberi tahu manajer sumber daya tentang setiap transaksi terdaftar yang sedang berlangsung sebelum crash dan transaksi mana yang harus dipulihkan oleh manajer sumber daya.

Jika klien transaksional bernama ZwCommitTransaction untuk transaksi sebelum crash, dan mulai menangani operasi penerapan untuk transaksi, manajer sumber daya harus dapat memulihkan status transaksi ke titik segera sebelum crash. Jika klien belum siap untuk melakukan transaksi sebelum crash, manajer sumber daya dapat membuang data dan mengembalikan transaksi.

Untuk informasi selengkapnya tentang cara menulis klien transaksi, lihat Membuat Klien Transaksi.

Untuk informasi selengkapnya tentang cara menulis manajer sumber daya, lihat Membuat Resource Manager.

Beberapa Resource Manager dalam TPS

Sekarang misalkan TPS Anda memungkinkan klien untuk memodifikasi informasi dalam dua database terpisah dalam satu transaksi, sehingga transaksi hanya berhasil jika modifikasi kedua database berhasil.

Dalam hal ini, TPS Anda dapat memiliki dua manajer sumber daya, satu untuk setiap database. Setiap manajer sumber daya dapat mengekspor API yang dapat digunakan klien untuk mengakses database manajer sumber daya.

Pseudocode berikut menunjukkan bagaimana klien dapat membuat satu transaksi yang berisi operasi pada dua database yang didukung dua manajer sumber daya.

Dalam contoh ini, klien membaca data dari database pertama dan menulisnya ke database kedua. Kemudian, klien membaca data dari database kedua dan menulisnya ke database pertama. (Manajer sumber daya pertama mengekspor fungsi yang dimulai dengan Rm1, dan manajer sumber daya kedua mengekspor fungsi yang dimulai dengan Rm2.)

    ZwCreateTransaction (&TransactionHandle, ...);
    ZwQueryInformationTransaction (TransactionHandle, ...);
    Rm1CreateDataObject (TransactionID, &Rm1DataHandle);
    Rm2CreateDataObject (TransactionID, &Rm2DataHandle);
    Status = Rm1ReadData (Rm1DataHandle, &Rm1Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm2WriteData (Rm2DataHandle, Rm1Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm2ReadData (Rm2DataHandle, &Rm2Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm1WriteData (Rm1DataHandle, Rm2Data);
    if (Status == Error) goto ErrorRollback;
    ZwCommitTransaction (TransactionHandle, ...);
    goto Leave;
ErrorRollback:
    ZwRollbackTransaction (TransactionHandle, ...);
Leave:
    ZwClose (TransactionHandle);
    return;

Karena klien meneruskan pengidentifikasi transaksi yang sama ke kedua manajer sumber daya, kedua manajer sumber daya dapat memanggil ZwOpenTransaction dan ZwCreateEnlistment untuk mendaftar dalam transaksi. Ketika klien akhirnya memanggil ZwCommitTransaction, KTM memberi tahu setiap manajer sumber daya bahwa manajer harus membuat operasi permanen, dan setiap manajer sumber daya memanggil ZwCommitComplete setelah selesai.

Skenario TPS Lainnya

KTM mendukung skenario TPS lainnya. Misalnya, skenario berikut menjelaskan komponen yang mungkin dimuat TPS:

  • Satu manajer sumber daya yang mengelola beberapa database.

    API manajer sumber daya dapat memungkinkan klien untuk membuka dan mengakses lebih dari satu database pada satu waktu, dan klien dapat menggabungkan akses ke beberapa database dalam satu transaksi.

  • Satu manajer sumber daya dengan API yang dipanggil klien, dan manajer sumber daya tambahan dengan API yang dipanggil manajer sumber daya pertama.

    Klien hanya berkomunikasi dengan manajer sumber daya pertama. Ketika manajer sumber daya memproses permintaan dari klien, manajer sumber daya tambahan dapat mengakses manajer sumber daya tambahan, sesuai kebutuhan, untuk memproses permintaan klien. Misalnya, manajer sumber daya mengelola database yang dapat diakses klien yang memerlukan operasi pencadangan atau verifikasi data dari manajer sumber daya kedua yang tidak tersedia untuk klien.

  • Klien dan manajer sumber daya yang ada yang tidak menggunakan KTM, terintegrasi dengan sekumpulan manajer sumber daya tambahan yang menggunakan KTM.

    Dalam hal ini, Anda biasanya harus memodifikasi manajer sumber daya yang ada sehingga menjadi manajer transaksi unggul yang berkomunikasi dengan KTM.