Android 的 JDBC 与 Web 服务 [英] JDBC vs Web Service for Android

问题描述

有人可以回答我的困境，使用哪种方法将 Android 设备连接到 mySQL 或 Postgresql?

Can someone answer on my dilemma which method to use for connecting Android device to mySQL or Postgresql?

两种方式我都可以做到，没有任何错误和问题，没有明显的区别，但每个人都建议使用 web 服务而不是使用 jdbc 驱动程序和直接连接，

I can do it in both ways without any errors and problems, with no noticeable difference but everyone recommend web service instead of using jdbc driver and direct connection,

有人可以用一些事实解释原因吗?

Can someone explain why with some facts?

我没有提到它更简单，并且通过 jdbc 完成它需要更少的时间.那么，为什么是 Web 服务，或者为什么不呢?

I did'n mention that is more simple and needs less time to do it over jdbc. So, why web service, or why not?

推荐答案

您认为使用 JDBC 更简单、更快捷，因为您没有考虑手机和便携式设备的实际操作环境设备.他们经常通过错误的流量重写代理和疯狂的防火墙来实现脆弱的连接.他们通常使用网络传输层，该层具有高且可变的丢包率和延迟，在短时间内变化多个数量级.在这种环境下，TCP 确实不是很好，尤其是与长寿命连接有关.

You think it's simpler and faster to do it with JDBC because you aren't considering the real world operating environment of phones and portable devices. They often have flakey connectivity through buggy traffic rewriting proxies and insane firewalls. They're typically using a network transport layer that has high and variable packet loss rates and latencies that vary over many orders of magnitude in short spans of time. TCP really isn't great in this environment and particularly struggles with long lived connections.

Web 服务的主要优势在于:

The key benefit of a web service is that it:

• 具有最短状态的短暂连接，因此当设备切换 WiFi 网络、与蜂窝网络、短暂失去连接等时，很容易回到原来的位置；和

• Has short-lived connections with minimal state, so it's easy to get back to where you were when the device switches WiFi networks, to/from cellular, loses connectivity briefly, etc; and

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

Can pass through all but the most awful and draconian web proxies

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

You will routinely encounter problems with a direct JDBC connection. One challenge is reliably timing out dead connections, re-establishing sessions and releasing locks held by the old session (as the server may not decide it's dead at the same time the client does). Another is packet loss causing very slow operations, long-running database transactions, and consequent problems with lock durations and transactional cleanup tasks. You'll also meet every variety of insane and broken proxy and firewall under the sun - proxies that support CONNECT but then turn out to assume all traffic is HTTPs and mangle it if it isn't; firewalls with buggy stateful connection tracking that cause connections to fail or go to a half-open zombie state; every NAT problem you can imagine; carriers "helpfully" generating TCP ACKs to reduce latency, never mind the problems that causes with packet loss discovery and window sizing; wacky port blocking; etc.

因为每个人 都使用 HTTP，所以您可以期望它能够工作 - 至少，比其他任何东西都更频繁.现在尤其如此，即使在移动 Web 应用程序中，常见的网站也使用 REST+JSON 通信方式.

Because everyone uses HTTP, you can expect that to work - at least, vastly more often than anything else does. This is particularly true now that common websites use REST+JSON communication style even in mobile web apps.

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

You can also write your web service calls to be idempotent using unique request tokens. That lets your app re-send modification requests without fear that it'll perform an action against the database twice. See idempotence and definining idempotence.

说真的，来自移动设备的 JDBC 现在看起来可能是个好主意 - 但我什至认为唯一的方法是移动设备都在我直接控制的单个高可靠 WiFi 网络上.即使这样，如果可能的话，出于数据库性能管理的原因，我也会避免使用它.您可以使用 PgBouncer 之类的东西在服务器端的许多设备之间建立连接池，因此连接池不是一个大问题，但是清理丢失和放弃的连接是，使其工作所需的 tcp keepalive 流量和长期停滞来自废弃连接的交易.

Seriously, JDBC from a mobile device might look like a good idea now - but the only way I'd even consider it would be if the mobile devices were all on a single high-reliably WiFi network under my direct control. Even then I'd avoid it for reasons of database performance management if I possibly could. You can use something like PgBouncer to pool connections among many devices at the server side so connection pooling isn't a big problem, but cleanup of lost and abandoned connections is, as is the tcp keepalive traffic required to make it work and the long stalled transactions from abandoned connections.

这篇关于Android 的 JDBC 与 Web 服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！