Bạn nghĩ rằng đơn giản hơn và nhanh hơn để làm điều đó với JDBC vì bạn không xem xét môi trường hoạt động trong thế giới thực của điện thoại và các thiết bị di động. Chúng thường có kết nối không ổn định thông qua proxy viết lại lưu lượng lỗi và tường lửa điên cuồng. Họ thường sử dụng lớp truyền tải mạng có tỷ lệ mất gói cao và thay đổi cũng như độ trễ thay đổi theo nhiều cấp độ lớn trong khoảng thời gian ngắn. TCP thực sự không tuyệt vời trong môi trường này và đặc biệt gặp khó khăn với các kết nối tồn tại lâu dài.
Lợi ích chính của một dịch vụ web là nó:
-
Có các kết nối tồn tại trong thời gian ngắn với trạng thái tối thiểu, vì vậy, thật dễ dàng để quay lại vị trí của bạn khi thiết bị chuyển mạng WiFi, đến / đi từ mạng di động, mất kết nối trong thời gian ngắn, v.v.; và
-
Có thể vượt qua tất cả, trừ những proxy web tồi tệ và hà khắc nhất
Bạn sẽ thường xuyên gặp sự cố với kết nối JDBC trực tiếp. Một thách thức là xác định thời gian đáng tin cậy của các kết nối đã chết, thiết lập lại các phiên và giải phóng các khóa do phiên cũ nắm giữ (vì máy chủ có thể không quyết định nó đã chết cùng lúc với máy khách). Một nguyên nhân khác là mất gói gây ra các hoạt động rất chậm, các giao dịch cơ sở dữ liệu kéo dài và hậu quả là các vấn đề với thời lượng khóa và các tác vụ dọn dẹp giao dịch. Bạn cũng sẽ gặp đủ loại proxy và tường lửa điên rồ và bị hỏng dưới ánh nắng mặt trời - những proxy hỗ trợ CONNECT nhưng sau đó hóa ra giả sử tất cả lưu lượng truy cập là HTTP và xử lý nó nếu nó không phải; tường lửa với tính năng theo dõi kết nối trạng thái có lỗi khiến kết nối không thành công hoặc chuyển sang trạng thái xác sống nửa mở; mọi vấn đề NAT mà bạn có thể tưởng tượng; nhà cung cấp dịch vụ "hữu ích" tạo TCP ACK để giảm độ trễ, không quan tâm đến các vấn đề gây ra với việc phát hiện mất gói và định cỡ cửa sổ; chặn cổng lập dị; vv
Bởi vì mọi người sử dụng HTTP, bạn có thể mong đợi điều đó hoạt động - ít nhất, thường xuyên hơn bất kỳ thứ gì khác. Điều này đặc biệt đúng khi các trang web phổ biến sử dụng kiểu giao tiếp REST + JSON ngay cả trong các ứng dụng web dành cho thiết bị di động.
Bạn cũng có thể viết các lệnh gọi dịch vụ web của mình thành Idempotent sử dụng mã thông báo yêu cầu duy nhất. Điều đó cho phép ứng dụng của bạn gửi lại các yêu cầu sửa đổi mà không sợ rằng nó sẽ thực hiện hành động chống lại cơ sở dữ liệu hai lần. Xem idempotence và định nghĩa lý tưởng .
Nghiêm túc mà nói, JDBC từ thiết bị di động bây giờ có thể là một ý tưởng hay - nhưng cách duy nhất tôi thậm chí sẽ xem xét là nếu tất cả các thiết bị di động đều nằm trên một mạng WiFi có độ tin cậy cao duy nhất dưới sự kiểm soát trực tiếp của tôi. Thậm chí sau đó, tôi sẽ tránh nó vì lý do quản lý hiệu suất cơ sở dữ liệu nếu tôi có thể. Bạn có thể sử dụng một cái gì đó như PgBouncer để gộp các kết nối giữa nhiều thiết bị ở phía máy chủ để việc gộp kết nối không phải là một vấn đề lớn, nhưng việc dọn dẹp các kết nối bị mất và bị bỏ rơi, cũng như lưu lượng truy cập giữ nguyên tcp cần thiết để làm cho nó hoạt động và lâu bị đình trệ giao dịch từ các kết nối bị bỏ rơi.
