Sự khác nhau giữa autoReconnect và autoReconnectForPools trong trình kết nối MySql/J là gì?

Question

Trong tham chiếu cấu hình cho MySql's connector J driver, một bộ trống báo trước được cấp khi sử dụng thuộc tính autoReconnect. Tôi đã làm theo hướng dẫn và tăng số máy chủ wait_timeout của máy chủ của tôi. Vì tôi đang sử dụng DBCP (Tôi đang cân nhắc việc chuyển sang c3po sau khi đọc một số bài đăng về việc tải xuống DBCP của Stackoverflow), bạn có thể sử dụng thuộc tính autoReconnectForPools không? Nó thực sự làm gì khi được kích hoạt theo DBCP hoặc bất kỳ nhóm kết nối nào cho vấn đề đó?

Answer 1

autoReconnect sẽ ném một SQLException cho máy khách, nhưng sẽ cố gắng thiết lập lại kết nối.

autoReconnectForPools sẽ cố ping máy chủ trước mỗi lần thực hiện SQL.

Tôi đã có rất nhiều vấn đề với dbcp trong quá khứ, đặc biệt là ngắt kết nối. Hầu hết đã được giải quyết bằng cách di chuyển đến c3p0. Lưu ý rằng trình điều khiển mysql có trình kiểm tra kết nối cho c3p0 (com.mysql.jdbc.integration.c3p0.MysqlConnectionTester).

Ngoài ra, bạn có thể muốn kiểm tra này: Connection pooling options with JDBC: DBCP vs C3P0

Answer 2

Bạn có chắc chắn bạn đang sử dụng DBCP đúng cách? Theo số short configuration notes, nó phải xử lý thời gian chờ khá tốt nhờ giá trị mặc định của testOnBorrow=true (kiểm tra kết nối trước khi sử dụng, và nếu nó thất bại nó được giảm từ hồ bơi và chúng tôi cố gắng để có được một cái mới để thay thế) .

Điều duy nhất bạn cần làm là đảm bảo bạn định cấu hình thuộc tính validationQuery thành Chuỗi không trống, ví dụ: "SELECT 0" cho cơ sở dữ liệu MySQL (here là một bài đăng về các giá trị xác thực khác nhau cho mỗi DB được sử dụng).

Answer 3

Tính năng autoReconnect của MySQL không còn được dùng vì có nhiều vấn đề (ref: chính thức documentation).

autoReconnectForPools có ít để làm với autoReconnect, nó có nhiều việc phải làm với autoCommit và reconnectAtTxEnd - khi tất cả 3 là true, nó sẽ ping máy chủ ở phần cuối của mỗi giao dịch và tự động kết nối nếu cần thiết.

Xác thực kết nối của DBCP là không hoàn hảo - ngay cả khi testOnBorrow được đặt, đôi khi trả về kết nối bị hỏng từ hồ bơi (chưa kể kiểm tra kết nối trước mỗi lần mượn không hiệu quả khủng khiếp).

Theo this article, HikariCP có vẻ là triển khai tốt hơn vì nó có thể sử dụng API JDBC4 isValid() nhanh hơn nhiều so với chạy truy vấn thử nghiệm và được thiết kế đặc biệt để không bao giờ trả về kết nối bị hỏng cho ứng dụng khách.