Lý do mã 68 đã cho bạn biết điều này là do thời gian chờ khóa (bế tắc là mã lý do 2) Có thể do người dùng khác đang chạy truy vấn cùng một lúc sử dụng cùng dữ liệu bạn đang truy cập hoặc nhiều bản cập nhật của riêng bạn.
Bắt đầu bằng cách chạy db2pd -db locktest -locks show detail từ dòng lệnh db2 để xem vị trí khóa. Sau đó, bạn sẽ cần phải chạy một cái gì đó như:
select tabschema, tabname, tableid, tbspaceid
from syscat.tables where tbspaceid = # and tableid = #
điền vào # ký hiệu với số ID bạn nhận được từ đầu ra lệnh db2pd.
Khi bạn thấy nơi ổ khóa là, đây là một số lời khuyên sau:
◦Deadlock tần số đôi khi có thể được giảm bằng cách đảm bảo rằng tất cả các ứng dụng truy cập dữ liệu chung của họ theo thứ tự - ý nghĩa, ví dụ, rằng họ truy cập (và do đó khóa) các hàng trong Bảng A, tiếp theo là Bảng B, tiếp theo là Bảng C, v.v.
lấy từ: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.trb.doc/doc/t0055074.html
khuyến khích đọc: http://www.ibm.com/developerworks/data/library/techarticle/dm-0511bond/index.html
Phụ Lục: nếu servlet của bạn hoặc ứng dụng khác có tội là sử dụng select báo cáo tìm thấy sẽ được tham gia vào thế bế tắc, bạn có thể thử phụ with ur minh báo cáo chọn nếu tính chính xác của dữ liệu mới được cập nhật (hoặc được chèn) không quan trọng.
Điều quan trọng cần lưu ý là bài viết nói về ** giảm ** tần suất deadlocks, không ** ngăn chặn ** chúng hoàn toàn. Theo http://stackoverflow.com/a/112256/14731 thứ tự khóa nhất quán không ngăn chặn deadlocks. Điều chúng ta có thể làm là cố gắng giảm tần suất của chúng. – Gili