您 认为
使用JDBC更为简单快捷，因为您没有考虑电话和便携式设备的实际操作环境。他们经常通过错误的流量重写代理和疯狂的防火墙来实现轻松的连接。他们通常使用的网络传输层具有高且可变的丢包率和延迟，这些延迟在很短的时间内变化了多个数量级。在这种环境下，TCP确实不是很好，特别是对于寿命长的连接而言，它尤其困难。

Web服务的主要好处是：

• 连接状态短暂，状态极少，因此当设备将WiFi网络切换到蜂窝网络，从蜂窝网络切换到无线网络，短暂失去连接等情况时，很容易回到原来的状态。和

• 可以通过除最糟糕和严酷的网络代理之外的所有代理

通常
，直接JDBC连接会遇到问题。挑战之一是可靠地使死连接超时，重新建立会话并释放旧会话持有的锁（因为服务器可能不会在客户端同时确定它已死）。另一个是数据包丢失，导致操作非常缓慢，数据库事务长时间运行以及随之而来的锁定持续时间和事务清除任务问题。您还将在阳光下遇到各种疯狂和损坏的代理和防火墙-
支持的代理CONNECT但是后来假设所有流量都是HTTP，如果不是，则对其进行处理；具有错误的状态连接跟踪的防火墙导致连接失败或进入半开僵尸状态；您可以想象的每个NAT问题；运营商“有帮助”地生成TCP
ACK以减少等待时间，不必理会丢包发现和窗口大小调整所引起的问题；古怪的端口阻塞；等等

因为 每个人都 使用HTTP，所以您可以期望它起作用-
至少比其他任何事情都更频繁地工作。尤其是现在，即使是在移动Web应用程序中，常见的网站也使用REST + JSON通讯样式，这尤其如此。

您还可以使用唯一的请求令牌将Web服务调用编写为 幂等的
。这样一来，您的应用就可以重新发送修改请求，而不必担心它将对数据库执行两次操作。请参见幂等和定义幂等。

认真地讲，现在从移动设备中获取JDBC似乎是一个好主意-
但我什至认为，唯一的方法是，如果这些移动设备全部都在我直接控制的单个高可靠性WiFi网络上。即使这样，如果可能的话，出于数据库性能管理的原因，我还是会避免使用它。您可以使用PgBouncer之类的方法在服务器端池化许多设备之间的连接，因此连接池不是什么大问题，但是清除丢失和废弃的连接是必需的，tcp
keepalive流量也需要清理，以使其正常工作并长时间停滞不前来自废弃连接的交易。