myślisz łatwiej i szybciej jest to zrobić z JDBC, ponieważ nie bierzesz pod uwagę rzeczywistego środowiska operacyjnego telefonów i urządzeń przenośnych. Często mają niestabilną łączność dzięki błędnym serwerom proxy przepisywania ruchu i szalonym zaporom. Zazwyczaj używają warstwy transportowej sieci, która ma wysokie i zmienne współczynniki utraty pakietów i opóźnienia, które zmieniają się o wiele rzędów wielkości w krótkich odstępach czasu. TCP naprawdę nie jest świetny w tym środowisku, a zwłaszcza ma problemy z długotrwałymi połączeniami.
Kluczową zaletą usługi internetowej jest to, że:
-
Ma krótkotrwałe połączenia z minimalnym stanem, więc łatwo jest wrócić do miejsca, w którym byłeś, gdy urządzenie przełącza sieci Wi-Fi na/z sieci komórkowej, na krótko traci łączność itp.; i
-
Może przechodzić przez wszystkie, oprócz najbardziej okropnych i drakońskich serwerów proxy
Będziesz rutynowo napotkać problemy z bezpośrednim połączeniem JDBC. Jednym z wyzwań jest niezawodne odmierzanie czasu martwych połączeń, ponowne ustanawianie sesji i zwalnianie blokad utrzymywanych przez starą sesję (ponieważ serwer może nie zdecydować, że jest martwy w tym samym czasie, co klient). Innym jest utrata pakietów powodująca bardzo powolne operacje, długotrwałe transakcje w bazach danych i wynikające z tego problemy z czasem trwania blokad i zadaniami czyszczenia transakcji. Spotkasz także różne szalone i zepsute serwery proxy i zaporę ogniową pod słońcem - serwery proxy obsługujące CONNECT ale potem okazuje się, że cały ruch to HTTP i zniekształca go, jeśli tak nie jest; zapory sieciowe z błędnym śledzeniem połączeń stanowych, które powodują awarię połączeń lub przechodzą do stanu półotwartego zombie; każdy problem NAT, jaki możesz sobie wyobrazić; operatorzy „pomocnie” generujący pakiety TCP ACK w celu zmniejszenia opóźnień, nie mówiąc już o problemach związanych z wykrywaniem utraty pakietów i określaniem rozmiaru okna; zwariowane blokowanie portów; itp.
Ponieważ wszyscy używa HTTP, możesz oczekiwać, że zadziała - przynajmniej znacznie częściej niż cokolwiek innego. Jest to szczególnie prawdziwe teraz, gdy popularne strony internetowe używają stylu komunikacji REST+JSON nawet w mobilnych aplikacjach internetowych.
Możesz także napisać swoje wywołania usług internetowych tak, aby były idempotentne przy użyciu unikalnych tokenów żądań. Dzięki temu Twoja aplikacja może ponownie wysyłać żądania modyfikacji bez obawy, że dwukrotnie wykona akcję na bazie danych. Zobacz idempotence i definiowanie idempotencji .
Poważnie, JDBC z urządzenia mobilnego może teraz wyglądać na dobry pomysł – ale jedyny sposób, jaki bym pomyślał, to gdyby wszystkie urządzenia mobilne były w jednej niezawodnej sieci Wi-Fi pod moją bezpośrednią kontrolą. Nawet wtedy unikałbym tego ze względu na zarządzanie wydajnością bazy danych, gdybym tylko mógł. Możesz użyć czegoś takiego jak PgBouncer, aby połączyć połączenia między wieloma urządzeniami po stronie serwera, więc łączenie połączeń nie jest dużym problemem, ale czyszczenie utraconych i porzuconych połączeń jest tak samo, jak ruch tcp keepalive wymagany do działania i długiego zablokowania transakcje z porzuconych połączeń.
