Giao thức Internet Liền mạng ORB: IIOP trong CORBA

FLAT TRANSACTION (GIAO DỊCH PHẲNG)

Ngoài ra còn có một kiểu khác là chained transaction nhưng không được hỗ trợ bởi OTS. Flat transaction là giao dịch có một khởi đầu và kết thúc đơn và chỉ có một mức (level) đơn. Chế độ flat transaction được hỗ trợ rộng rãi trong công nghiệp ngày nay trong các hệ thống xử lý giao dịch như CICS của IBM và ENCINA của Transarc cũng như các hệ cơ sở dữ liệu của IBM, Oracle và Sybase.

Đây cũng là khái niệm cơ bản cho mô hình xử lý giao dịch phân bố của X/Open và chuẩn OSI-TP của ISO.

NESTED TRANSACTION (GIAO DỊCH LỒNG NHAU)

Mô hình giao dịch nested transaction cho phép tạo ra các giao dịch mới và nhúng vào các giao dịch có sẵn để tạo thành một cây giao dịch (Được minh họa trong hình 5.1). Các giao dịch có sẵn được gọi là các giao dịch cha (parent), các giao dịch được nhúng vào là các giao dịch con (subtransaction) và được gọi là các child. Các subtransaction có thể được nhúng vào các subtransaction khác để tạo thành nhiều cấp lồng nhau.

Các hậu duệ (descendant) của một giao dịch là các con của một giao dịch. Một giao dịch không thể commit trừ khi tất cả các con của nó đã hoàn tất. Khi một giao dịch roll back, tất cả các con của nó cũng roll back.

Một giao dịch ở mức cao nhất (top-level) là một giao dịch không có các giao dịch cha. Một flat transaction có thể được xem như là một giao dịch ở mức cao nhất và không có các giao dịch con. Một top-level transaction và các giao dịch con của nó tạo thành một họ giao dịch (transaction family).

Các subtransaction có tính chất atomic; Tuy nhiên khi một subtransaction commit các thay đổi của nó còn chưa được giải quyết cho đến khi tất cả các ancestor của nó đều commit. Vì thế các subtransaction không có tính bền vững (durable), chỉ có các giao dịch top-level mới có tính bền vững. Khi một giao dịch có nhiều con, một con sẽ được thực thi một cách tuần tự sau các anh em của nó, ngay cả khi chúng thực hiện đồng thời.

Một subtransaction có thể thất bại mà không làm thất bại một họ giao dịch, điều này được gọi là failure granularity.

DỊCH VỤ GIAO DỊCH ĐỐI TƯỢNG (OBJECT TRANSACTION SERVICE) CỦA OMG

Trong suốt quá trình giao dịch, yêu cầu cũng có thể được thực hiện (3) trên các đối tượng recoverable. Các đối tượng giao dịch được dùng để hiện thực hai kiểu ứng dụng server là transactional và recoverable.  Một transactional server là một tập các đối tượng mà hành vi của chúng ảnh hưởng bởi giao dịch, nhưng dữ liệu của chúng không có trạng thái recoverable.

Nó không tham gia vào toàn bộ quá trình giao dịch nhưng có thể làm cho giao dịch rollback.  Một recoverable server là một tập các đối tượng, và có ít nhất là một đối tượng có trạng thái recoverable. Nó tham gia vào toàn bộ quá trình giao dịch bằng cách đăng ký với đối tượng Resource (tài nguyên) (4).

Đối tượng Resource hiện thực quá trình hoàn tất giao dịch bằng cách tham gia (5) vào quá trình hai pha two-phase commit. Với mỗi giao dịch hoạt động, OTS giữ một transaction context (ngữ cảnh giao dịch) để kết hợp với các tác vụ giao dịch. Một transaction context là một tham số ngầm định của các tác vụ giao dịch và được ORB chuyển đi cùng với các tác vụ như đã đề cập trong phần 5.3.1.

(1) Not involved in Registers resource (5) Begin transaction in transaction Participates or end completion; completion; may in transaction Transaction may force rollback force rollback completion.

VÍ DỤ VỀ DỊCH VỤ GIAO DỊCH

Như đã nói trước đây, begin tác vụ tạo ra một giao dịch mới, và transaction context của nó kết hợp với luồng điều khiển của client. Nếu đối tượng điều khiển này được trao cho tác vụ resume như một đối số thì sẽ tạo ra sự kết hợp giữa context với luồng thực thi của giao dịch. Điều đó có nghĩa là khi chúng ta gọi tác vụ suspend rồi resume một cách tuần tự với cùng một đối số là đối tượng điều khiển thì các tác vụ giữa hai lời gọi này không phải là các tác vụ của giao dịch cho đến khi có lời gọi tác vụ resume.

Ví dụ này thực hiện như sau : đầu tiên sẽ hỏi xem kho chứa có đủ sản phẩm cần thiết hay không. Nếu đủ thì giảm số lượng hàng trong kho và thêm cùng một số lượng hàng như vậy vào đơn đặt hàng. Khi commit, hai tác vụ trên được cập nhật đồng thời, giả sử không có ngoại lệ nào được tạo ra bởi hai đối tượng Inventory và Purchase.

Còn có một tập hợp giao tiếp khác sẽ được dùng nếu muốn có một sự nhân bản tường minh, tuy nhiên chúng ta sẽ không đề cập đến chúng ở đây. Còn một giao tiếp nữa cho thấy một cách cô đọng vài thông tin quan trọng về cách hoạt động của quá trình hai pha two-phase commit. Nếu không có dữ liệu persistent nào bị sửa đổi trong giao dịch thì resource sẽ trả về VoteReadOnly.

Nếu resource được chuẩn bị để commit, có nghĩa là các dữ liệu persistent đã được ghi vào các phương tiện lưu trữ (mặc dù điều này có thể không biểu hiện ra bên ngoài), nó sẽ trả về VoteCommit. Tuy vậy, resource vẫn còn phải chuẩn bị để roll back, bởi vì có thể một trong số các resource khác trong giao dịch không thể xử lý xong phần của nó. Và trường hợp cuối cùng là resource không được chuẩn bị để commit hoặc nó không biết về giao dịch hiện hành (giả sử rằng thông tin về giao dịch đã bị mất do hệ thống bị crash) thì nó sẽ trả về trị VoteRollback.

Giống như VoteReadonly, trị trả về này thông báo rằng resource không có mối quan hệ nào với giao dịch kể từ đây. Nó đòi hỏi recoverable server phải ghi nhớ các trạng thái của giao dịch và có thể phục hồi đúng các trạng thái này từ các thông tin đã được ghi nhận trong tác vụ prepare. Các tác vụ rollback và commit không có gì thay đổi, tác vụ commit tạo ra một ngoại lệ (exception) NotPrepared nếu tác vụ prepare không được thực hiện trước.