Bài viết sưu tầm

Một sự bế tắc (deadlock) xuất hiện khi hai hoặc nhiều các ứng dụng được nối tới cùng cơ sở dữ liệu. Sự chờ đợi chưa bao giờ được giải quyết bởi vì mỗi ứng dụng đang giữ một tài nguyên mà nó phục vụ cho những nhu cầu khác nhau. Trong thiết kế ứng dụng, những sự bế tắc luôn là một vấn đề chiếm nhiều thời gian

Trong hình trên, người A giữ được bột nho khô và giả sử sẽ không cho phép người khác dùng cho đến khi ông ta có sữa. Mặc khác, người B giữ được sữa và sẽ không cho phép người khác cho đến khi ông ta có bột nho khô. Bởi vậy, chúng ta có một tình huống bế tắc.

Để mô phỏng một tình huống bế tắc ở DB2, theo những bước sau đây:

1.     Mở hai cửa sổ soạn thảo lệnh của DB2 (chúng tôi sẽ gọi là “CLP1” và “CLP2” tương ứng). Chúng đại diện cho hai ứng dụng khác nhau kết nối tới cơ sở dữ liệu.

2.     Từ CLP1 thực hiện các lệnh sau:

db2 connect to sample
db2 +c update employee set firstnme = ‘Mary’ where empno =
‘000050’

Đầu tiên chúng ta đang kết nối đến cơ sở dữ liệu có tên SAMPLE, và sau đó thực hiện một lệnh cập nhật hàng trên bảng employee làm với “empno=50000”. Lựa chọn “+c” trong câu lệnh chỉ ra rằng, chúng tôi không muốn cửa sổ lệnh của DB2 tự động cam kết lệnh này. Chúng ta đang cố ý làm điều này sao cho chúng ta giữ được khoá.

3.     Từ CLP2 thực hiện những lệnh sau:

db2 connect to sample
db2 +c update employee set firstnme = ‘Tom’ where empno =
‘000030’

Ở cửa sổ của CLP2, nó đại diện cho ứng dụng thứ hai, chúng ta cũng nối vào cơ sở dữ liệu SAMPLE, nhưng lại cập nhật một hàng khác ở bảng employee

4.     Lệnh từ CLP1:

db2 +c select firstnme from employee where empno = ‘000030’

Sau khi nhấn Enter thực hiện câu lệnh SELECT ở trên, câu lệnh SELECT có vẻ sẽ treo. Nó thực sự là không phải là treo, mà là đợi khoá của hàng này trả về do CLP2 đã giữ trong bước 3. Tại điểm này, nếu CLOCKTIMEOUT đã được để lại với giá trị ngầm định của nó là -1, ứng dụng CLP1 đợi mãi mãi

5.     Lệnh từ CLP2:

b2 +c select firstnme from employee where empno = ‘000050’

Bằng việc đánh lệnh SELECT ở trên, bây giờ chúng ta đang tạo ra một sự bế tắc. Phát biểu SELECT này cũng có vẻ treo, thực ra nó đang đợi khoá CLP1 đang giữ trả về.

Trong kịch bản bế tắc trên, DB2 sẽ kiểm tra tham số cấu hình cơ sở dữ liệu DLCHKTIME. Tham số này sẽ đặt khoảng thời gian kiểm tra cho những sự bế tắc. Chẳng hạn, giá trị của tham số này được đặt tới 10 giây, DB2 sẽ sử dụng một giải thuật bên trong để xác định giao dịch nào cần phải quay lui, và một giao dịch nào sẽ được tiếp tục.

Nếu bạn đang gặp nhiều tình huống bế tắc, bạn cần phải tái kiểm tra những gioa dịch hiện hữu xem xem có thể tổ chức lại được không.