Mức cô lập CÓ THỂ XỬ LÝ TRONG Spring-JDBC

TL; DR:Việc phát hiện xung đột khả năng tuần tự hóa được cải thiện đáng kể trong Pg 9.1, vì vậy hãy nâng cấp.

Thật khó để tìm ra từ mô tả của bạn SQL thực sự là gì và tại sao bạn mong đợi nhận được khôi phục. Có vẻ như bạn đã hiểu lầm nghiêm trọng về tính cách ly có thể tuần tự hóa, có lẽ nghĩ rằng nó kiểm tra hoàn hảo tất cả các vị từ, điều này không xảy ra, đặc biệt là không phải trong Trang 8,4.

SERIALIZABLE không hoàn toàn đảm bảo rằng các giao dịch thực hiện như thể chúng được chạy theo chuỗi - vì làm như vậy sẽ rất tốn kém theo quan điểm hiệu suất nếu điều đó là có thể. Nó chỉ cung cấp kiểm tra giới hạn. Chính xác những gì được kiểm tra và thay đổi như thế nào giữa cơ sở dữ liệu này sang cơ sở dữ liệu và phiên bản này sang phiên bản khác, vì vậy bạn cần đọc tài liệu cho phiên bản cơ sở dữ liệu của mình.

Có thể xảy ra bất thường, trong đó hai giao dịch được thực hiện trong SERIALIZABLE chế độ tạo ra một kết quả khác nếu các giao dịch đó thực sự được thực hiện theo chuỗi.

Đọc tài liệu về cách ly giao dịch trong Pg để tìm hiểu thêm. Lưu ý rằng SERIALIZABLE đã thay đổi hành vi đáng kể trong Pg 9.1, vì vậy hãy đảm bảo đọc phiên bản hướng dẫn sử dụng phù hợp với phiên bản Pg của bạn. Đây là phiên bản 8.4 . Cụ thể, hãy đọc 13.2.2.1. Cách ly có thể nối tiếp so với Khả năng nối tiếp thực sự . Bây giờ so sánh điều đó với hỗ trợ tuần tự hóa dựa trên khóa vị từ được cải thiện đáng kể được mô tả trong Tài liệu trang 9.1 .

Có vẻ như bạn đang cố gắng thực hiện logic giống như mã giả này:

count = query("SELECT count(*) FROM the_table");
if (count < threshold):
    query("INSERT INTO the_table (...) VALUES (...)");

Nếu vậy, điều đó sẽ không hoạt động trong Pg 8.4 khi được thực thi đồng thời - nó khá giống với ví dụ bất thường được sử dụng trong tài liệu được liên kết ở trên. Thật ngạc nhiên là nó thực sự hoạt động trên Pg 9.1; Tôi không mong đợi việc khóa vị từ của 9.1 thậm chí có thể sử dụng các tổng hợp.

Bạn viết rằng:

nhưng 8.4 sẽ không phát hiện ra rằng hai giao dịch phụ thuộc lẫn nhau, điều mà bạn có thể chứng minh bằng cách sử dụng hai psql các phiên để kiểm tra nó. Chỉ với những thứ có khả năng tuần tự hóa thực sự được giới thiệu trong 9.1 thì điều này sẽ hoạt động - và thành thật mà nói, tôi đã rất ngạc nhiên khi nó hoạt động trong 9.1.

Nếu bạn muốn thực hiện điều gì đó như thực thi số hàng tối đa trong Trang 8.4, bạn cần LOCK cái bàn để ngăn INSERT đồng thời s, thực hiện khóa theo cách thủ công hoặc thông qua chức năng kích hoạt . Làm điều đó trong một trình kích hoạt vốn dĩ sẽ yêu cầu thăng chức khóa và do đó sẽ thường xuyên bế tắc, nhưng sẽ thực hiện thành công công việc. Nó được thực hiện tốt hơn trong ứng dụng nơi bạn có thể phát hành LOCK TABLE my_table IN EXCLUSIVE MODE trước khi lấy được SELECT chẵn ing từ bảng, vì vậy nó đã có chế độ khóa cao nhất mà nó sẽ cần trên bàn và do đó không cần quảng cáo khóa dễ bị deadlock. EXCLUSIVE chế độ khóa thích hợp vì nó cho phép SELECT s chứ không có gì khác.

Đây là cách kiểm tra nó trong hai phiên psql:

SESSION 1                               SESSION 2

create table ser_test( x text );

BEGIN TRANSACTION 
ISOLATION LEVEL SERIALIZABLE;


                                        BEGIN TRANSACTION 
                                        ISOLATION LEVEL SERIALIZABLE;

SELECT count(*) FROM ser_test ;

                                        SELECT count(*) FROM ser_test ;

INSERT INTO ser_test(x) VALUES ('bob');


                                        INSERT INTO ser_test(x) VALUES ('bob');

 COMMIT;

                                        COMMIT;

Khi chạy trên trang 9.1, st commits succeeds then the second thứ hai COMMIT` không thành công với:

regress=# COMMIT;
ERROR:  could not serialize access due to read/write dependencies among transactions
DETAIL:  Reason code: Canceled on identification as a pivot, during commit attempt.
HINT:  The transaction might succeed if retried.

nhưng khi chạy trên 8.4 thì cả hai cam kết đều thành công, vì 8.4 không có tất cả mã khóa vị từ cho khả năng tuần tự hóa được thêm vào 9.1.