Có rất nhiều định nghĩa khác nhau về transaction, xin mạn phép đưa ra một định nghĩa dưới đây.

Transaction là một tiến trình xử lý có xác định điểm đầu và điểm cuối, được chia nhỏ thành các operation (phép thực thi) , tiến trình được thực thi một cách tuần tự và độc lập các operation đó theo nguyên tắc hoặc tất cả đều thành công hoặc một operation thất bại thì toàn bộ tiến trình thất bại. Nếu việc thực thi một operation nào đó bị fail (hỏng) đồng nghĩa với việc dữ liệu phải rollback (trở lại) trạng thái ban đầu.

Như vậy, xét một cách chung nhất, transaction không phải là thuật ngữ gắn với business cụ thể nào cũng không phải là thuật ngữ chỉ gắn chặt vào data storage (bao gồm cả RDBMs – cơ sở dữ liệu quan hệ). Transaction là một thuật ngữ chung nhất design cho một tiến trình xử lý trong phần mềm với những yêu cầu được vạch ra hàm chứa trong định nghĩa.

Ví dụ: Đơn giản nhất là tiến trình cài đặt phần mềm hoặc gỡ bỏ phần mềm có thể coi là một transaction. Việc cài đặt được chia thành các bước, thực hiện tuần tự từ đầu đến cuối, nếu toàn bộ các bước thực thi thành công đồng nghĩa với việc tiến trình cài đặt hoặc gỡ bỏ phần mềm thành công và ngược lại, một phép thất bại thì tiến trình phải rollback lại tức sẽ không có bất kỳ thay đổi nào trên máy tính (ghi file, sửa các registry,…)

Chúng ta cần chú ý đến 5 nhân tố chính để xác định có phải là một transaction hay không?

1. Tiến trình xử lý cần xác định chính xác điểm đầu và điểm cuối, tức khi nào được coi là bắt đầu, khi nào được coi như kết thúc, không có sự nhập nhằng ranh giới.

2. Tiến trình phải được chia nhỏ thành các operation – phép thực thi đến mức không thể chia nhỏ hơn.

3. Thực thi một cách tuần tự các operations. Có hai nguyên tắc căn bản là từ đầu đến cuối (trái sang phải hoặc trên xuống dưới) và từ trong ra ngoài. Việc thực thi các operation là độc lập, không có chuyện đang thực thi operation A lại quay sang thực thi operation B rồi mới quay lại thực thi operation A tiếp.

4. Nguyên lý “either all occur, or nothing occurs” hoặc tất cả các operation đều thực thi thành công thì tiến trình mới được coi là thành công. Nếu chỉ một operation thực thi thất bại thì coi như toàn bộ transaction là thất bại.

5. Nếu transaction thất bại thì toàn bộ dữ liệu (dữ liệu nói chung, có thể trong memory, file trên đĩa cứng, dữ liệu trên thiết bị ngoại vi, dữ liệu trong cơ sở dữ liệu quan hệ,…) phải trở lại (rollback) trạng thái ban đầu. Nghĩa là dữ liệu tạo mới phải bị xóa, sửa thì phải thay đổi lại đúng những gì trước khi sửa, dữ liệu lỡ xóa thì phải khôi phục lại,…

Kiểu của transaction

Các kiểu transaction khác nhau được phân biệt bằng việc chia các operation như thế nào. Có hai kiểu (mô hình) transaction– transaction models là:

1. Flat Transaction – ngang hàng: Việc chia các operation là ngang hàng nhau

Thực thi các operation là tuần tự từ trái sang phải hoặc từ trên xuống dưới.

2. Nested Transaction – lồng nhau: Các operation lồng nhau

Việc thực thi các operation dựa theo nguyên tắc từ trong ra ngoài. Như vậy khi nhìn vào hình vẽ chúng ta thấy các operation ở dạng này có vẻ phụ thuộc vào nhau nhưng khi thực thi thì là độc lập theo nguyên tắc operation trong thực thi xong thì mới đến operation ngoài.

ACID properties trong transaction.

Mô hình ACID được gắn chặt với cơ sở dữ liệu quan hệ. Tuy nhiên, xét về transaction nói chung, chúng ta cũng có thể áp dụng các thuộc tính này vào. Xin được xem xét các đặc điểm của ACID chi tiết dưới đây.

• Atomicity – tính đơn vị: Một transaction xác định ranh giới của nó rất rõ ràng, tức xác định điểm bắt đầu và kết thúc của tiến trình. Như vậy có thể coi nó như một đơn vị thực thi và đơn vị thực thi này thực hiện theo nguyên tắc “all or nothing”. Nghĩa là nếu một thành phần nào đó trong transaction thực thi hỏng (fail) thì đồng nghĩa với việc không có gì xảy ra tức không có gì thay đổi về mặt dữ liệu.
• Consistency – nhất quán: Dữ liệu nhất quán với transaction ở thời điểm bắt đầu và kết thúc. Nhất quán ở transaction là strong consistency. Để tìm hiểu kỹ hơn về tính nhất quán, xin đọc lại bài viết NoSQL.
• Isolation – độc lập: Nếu hai transaction thực thi cùng lúc thì nguyên tắc thực thi là thực thi độc lập. Nghĩa là một transaction không thể “nhìn thấy” một transaction khác. “Không nhìn thấy” ở đây là không tác động lẫn nhau, chủ yếu trên dữ liệu.
• Durability – bền vững: Dữ liệu của transaction sau khi thực thi xong được cố định, chính thức và bền vững. Nghĩa là những thay đổi đã được cố định, không có chuyện có thể chuyển lại trạng thái dữ liệu lúc trước khi thực hiện transaction.

Rủi ro khi thực thi transaction

Có ba loại rủi ro chính khiến việc thực thi một transaction có thể bị fail.

1. Việc thực thi operation bị hỏng: rõ ràng việc này sẽ dẫn tới transaction bị hỏng. Điều này đã được quy định rõ trong định nghĩa về transaction.

2. Vấn đề về phần cứng và mạng: việc phần cứng hoặc mạng có vấn đề trong lúc đang thực thi transaction sẽ dẫn đến tiến trình xử lý thất bại.

3. Các vấn đề với dữ liệu dùng chung: Đây là vấn đề khó nhất. Rõ ràng data là một tài nguyên dùng chung, do đó sẽ có những nguy cơ mà transaction gặp phải khi xử lý dữ liệu dùng chung này. Ta sẽ xem xét kỹ hơn dưới đây.

Như chúng ta đã biết, phần mềm viết ra là để xử lý dữ liệu, 2 operations (phép) căn bản của phần mềm với dữ liệu là đọc và ghi (read và write) trong đó phép write lại được chia nhỏ thành 3 operations nhỏ hơn là insert (thêm mới), update (sửa), delete (xóa).

Dữ liệu là một tài nguyên dùng chung, nếu như có nhiều tiến trình xử lý đồng thời thực hiện các phép trên dữ liệu sẽ xảy ra những rủi ro: write-write, write-read,… việc dữ liệu ghi cùng lúc dẫn tới hỏng dữ liệu hoặc dữ liệu đọc ra không đồng nhất với dữ liệu mới ghi vào,… sẽ đề cập kỹ hơn trong phần tiếp theo dưới đây.

Transaction Isolation Levels

Như đã đề cập ở trên, isolation – tính độc lập là một thuộc tính transaction tránh được những rủi ro do phải chung chạ data với các tiến trình xử lý khác. Khi có đồng thời 2 tiến trình xử lý trở lên, chúng ta sẽ có thể sẽ mắc phải database anomalies – cơ sở dữ liệu dị thường ( còn gọi là read phenomena – vấn đề đọc hoặc isolation problems) với 3 loại chính:

Dirty reads xảy ra khi transaction A tiến hành phép write với dữ liệu, transaction B tiến hành đọc dữ liệu sau khi A làm xong phép write. Tuy nhiên vì một lý do gì đó, transaction A không commit được, do đó sự thay đổi phép write không được chấp nhận, dữ liệu rollback lại trạng thái ban đầu, khi đó dữ liệu của B sẽ trở thành dirty – bẩn.

Nonrepeatable reads xảy ra khi transaction A tiến hành phép read trên dữ liệu, sau đó transaction B thực hiện phép write làm dữ liệu thay đổi, lần kế tiếp A lại tiến hành phép read với chính dữ liệu. Như vậy, 2 lần đọc của A thấy dữ liệu không nhất quán (consistency) trên cùng một bản ghi.

Phantom reads là rủi ro xảy ra với lệnh read có điều kiện (chẳng hạn mệnh đề where trong sql). Transaction A đọc được một số X dữ liệu thỏa mãn điều kiện 1, transaction B tiến hành phép write sinh ra một lượng Y dữ liệu thỏa mãn điều kiện , A tính toán lại với điều kiện 1 thấy bổ sung thêm một lượng Y dữ và tổng dữ liệu giữa 2 lần trở lên không đồng nhất.

Như vậy, để tránh được các trường hợp của database anomalies chúng ta cần phải locks data – khóa dữ liệu, không cho những tiến trình xử lý khác thực hiện các operations trên dữ liệu khi transaction hiện thời đang làm việc và việc khóa này sẽ được mở (giải phóng) ở cuối transaction. Có 3 loại lock khác nhau gồm write locks, read locks, rang locks và isolation levels chỉ ra những mức độ locks khác nhau trên dữ liệu hay nói một cách khác là mức độ “ẩn” khác nhau của một transaction với các transactions khác đang thực thi ở cùng thời điểm. Dưới đây là danh sách isolation levels:

Serializable: Đây là mức cao nhất của isolation levels, đảm bảo read và write locks. Trong trường hợp phép read có mệnh đề điều kiện, Serializable cũng cần đòi hỏi range lock để tránh phantom reads.

Repeatable Reads: là mức thấp hơn Serializable có read và write locks nhưng không cần đến range locks. Với trường hợp này, phantom reads có thể xảy ra.

Read committed: Chỉ bao gồm write locks, như vậy read committed chỉ đảm bảo dirty reads là không xảy ra.

Read uncommitted: Mức thấp nhất trong isolation levels trong đó cả ba dirty reads, nonrepeatable reads, phantom reads đều có thể xảy ra.

Nguồn tham khảo

IBM: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzaha%2Ftransiso.htm
Aptech Book: EJB 2
Wikipedia:
http://en.wikipedia.org/wiki/Transaction_processing
http://en.wikipedia.org/wiki/Database_transaction
http://en.wikipedia.org/wiki/Atomic_transaction