網上有很多關于pos機器tcp超時,深入了解JDBC超時機制的知識，也有很多人為大家解答關于pos機器tcp超時的問題，今天pos機之家(www.tonybus.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
pos機器tcp超時
現象：
數據庫出現各類問題和故障時候，例如連接數到達上限無法降低，數據庫宕機，網絡出現故障導致數據庫無法訪問，這時候應用服務器出現得不到連接，在數據庫重啟，或者主備切換，網絡恢復后，應用服務器很多連接仍然無法恢復，必須重啟應用服務器才能解決。針對以上情況現需要對JDBC的超時問題做深入的分析，通過在應用程序中配置恰當的 JDBC 超時時間來減少服務失敗的時間。
為什么我們需要知道 JDBC 驅動
當有性能問題或系統級錯誤時，應用服務器和數據庫是我們關注的兩個重要層面。但應用服務器和數據庫之間的部分會因為得不到足夠的關注而產生盲區。對于 java 應用，這個盲區在數據庫連接池和 JDBC 之間，本文我們將重點討論 JDBC。
什么是 JDBC 驅動
JDBC 是 Java 應用程序中用于訪問數據庫的一套標準 API，Sun 公司定義了四種類型的JDBC驅動。我司主要用的是第4種，該類型驅動由純 Java 語言編寫，在 Java 應用中通過 socket 與數據庫通信。
圖1: 類型4驅動
類型4驅動是通過 socket 來處理字節流的，它的基本操作和 HttpClient 這種網絡操作類庫相同。同其他網絡類庫一樣，也會在發生超時的時候占用大量的 CPU 資源從而失去響應。如果你之前用過 HttpClient ，肯定遇到過因為沒有設置超時導致的錯誤。如果 socket 超時設置不合適，類型4驅動也可能有同樣的錯誤（連接被阻塞）。
下面讓我們了解如何配置 JDBC 驅動的 socket 超時，以及設置時需考慮哪些問題。
WAS 與數據庫間的設置超時的層次
圖2: 超時的層次
圖2展示了簡化的 WAS 和數據庫通信時的超時層次。
更上層的超時依賴于下層的超時，只有當較低層的超時機制正常工作，上層的超時才會正常。如果 JDBC 驅動程序的 socket 超時工作不正常，那么更上層的超時比如 statement 超時和事務超時都不會正常工作。
這就說明了為何有時候即使配置了 Statement 超時，應用程序還是不能從故障中恢復，因為 Statement 超時在網絡故障時不起作用。
它只能做到：限制一次Statement 執行的時間，處理超時以防網絡故障必須由 JDBC 驅動來做。
JDBC 驅動的 socket 超時還會受操作系統的 socket 超時配置的影響。這解釋了有的時候 JDBC 連接在網絡故障后阻塞了30分鐘還能恢復，即使沒配置 JDBC 驅動的 socket 超時。
DBCP 連接池位于圖2的左邊。你會發現各種層面的超時與 DBCP 是分開的。DBCP 負責數據庫連接（即本文中說到的Connection）的創建和管理，并不涉及超時的處理。當在 DBCP 中創建了一個數據庫連接或發送了一條查詢校驗的 sql 語句用于檢查連接有效性時，socket 超時會影響這些過程的處理，但并不直接影響應用程序。
然而在應用程序中調用 DBCP 的 getConnection() 方法時，你能指定應用程序獲取數據庫連接的超時時間，但這和 JDBC 的連接超時無關。
圖3: 每一層級的超時
什么是事務超時
事務超時是在Spring框架或應用程序層面上才有效的超時。
事務超時可能是個不常見的概念。簡單講，事務超時等于 Statement 超時 * N（需要執行的 Statement 的數量） + 其它（垃圾回收等其他時間）。事務超時被用來限制執行一個事務之內所有 Statement 執行的總時長。
假設一個事務里有5條 Statement ，每條 Statement 執行時間是200毫秒，其它業務邏輯或框架操作的執行時間是100毫秒，那事務允許的超時時間至少應該1100毫秒（200 * 5 + 100）。
Spring 提供的事務超時的配置非常簡單，它會記錄每個事務的開始時間和消耗時間，當特定的事件發生時會對已消耗掉的時間做校驗，如果超出了配置將拋出異常。
Spring 中數據庫連接被保存在線程本地變量（ThreadLocal）中，這被稱作事務同步（Transaction Synchronization）。當數據庫連接被保存到 ThreadLocal 時，同時會記錄事務的開始時間和超時時間。所以通過數據庫連接的代理創建的 Statement 在執行時就會校驗這個時間。
什么是 Statement 超時
Statement 超時是用來限制 Statement 的執行時間的，它的具體值是通過 JDBC API 來設置的。JDBC 驅動程序基于這個值進行 Statement 執行時的超時處理。Statement 超時是通過 JDBC API 中java.sql.Statement 類的 setQueryTimeout(int timeout) 方法配置的。不過現在的開發者已經很少直接在代碼中配置它了，更多是通過框架來進行設置。
以 iBatis 為例，可以通過 SqlMapConfig.xml 中的 setting 屬性defaultStatementTimeout 來設置全局的 statement 超時缺省值。你也可以通過在具體的 sql 映射文件中的 select insert update 標簽的 statement 屬性來覆蓋。
MySql (5.X 中的 Statement 超時處理)
調用 Connection 的 createStatement() 方法創建一個 Statement 對象調用 Statement 的 executeQuery() 方法Statement 對象通過內部的 Connection 對象將查詢命令傳輸到 MySql 數據庫Statement 創建一個新的超時執行線程(timeout-execution)來處理超時5.1以上版本改為每個連接分配一個線程向 timeout-execution 線程注冊當前的 Statement 對象發生超時timeout-execution 線程創建一個相同配置的 Connection 對象用新創建的 Connection 發送取消查詢的命令圖4 MySQL 的 Statement 超時執行過程
什么是 Socket 超時
類型4的 JDBC 驅動是用 socket 方式與數據庫連接的，應用程序和數據庫之間的連接超時并不是由數據庫處理的。
當數據庫突然宕掉或發生網絡錯誤（設備故障等）時，JDBC 驅動的 socket 超時的值是必須的。由于 TCP/IP 的結構，socket 沒有辦法檢測到網絡錯誤，因此應用不能檢測到與數據庫到連接斷開了。如果沒有設置 socket 超時，應用程序會一直等待數據庫返回結果。（這個連接也被叫做“死連接”） 為了避免死連接，socket 必須要設置超時時間。socket 超時可以通過 JDBC 驅動程序配置。通過設置 socket 超時，可以防止出現網絡錯誤時一直等待的情況并縮短故障時間。
不推薦使用 socket 超時來限制一個 statement 的執行時間，因此socket 超時的值必須要高于 statement 的超時時間，否則 socket 超時將會先生效，這樣 statement 超時就沒有意義，也無法生效。
下面展示了 socket 超時設置的連個選項，其配置因不同的驅動而異。
socket 連接時的超時：通過 Socket 對象的 connect(SocketAddress endpoint, int timeout) 方法來配置socket 讀寫時的超時：通過 Socket 對象的 setSoTimeout(int timeout) 方法來配置下面列出了如何MySQL配置 socket 超時
連接超時配置: connectTimeout（默認值：0，單位：毫秒）
socket 超時配置: socketTimeout（默認值：0，單位：ms）
JDBC Url 格式:jdbc:mysql://[host:port],[host:port].../[database]
[?propertyName1][=propertyValue1][&propertyName2][=prop
connectTimeout 和 socketTimeout 的默認值是 0 ，這意味著不會發生超時。
操作系統層面的 socket 超時配置
如果沒設置 socket 超時或連接超時，應用程序多數情況下無法檢測到網絡錯誤。此時，應用程序將一直等待下去，直到連接上數據庫或能讀取到數據。然而，遇到的實際情況會發現問題常常在在應用程序在30分鐘后嘗試重新連接到網絡后被解決了。這是因為操作系統也配置了 socket 超時時間。Linux 服務器將 socket 超時時間設置為30分鐘。它將在操作系統層面對網絡連接做校驗。
通常，應用程序會在調用 socket 的 read() 方法時由于網絡問題而阻塞住。然而很少在調用 socket 的 write() 方法時處于等待狀態，這取決于網絡構成和錯誤類型。當應用程序調用 socket 的 write() 方法時，數據被記錄到操作系統的內核緩沖區，然后將控制權立即交還給應用程序。因此，一旦數據已經寫入內核緩沖區，socket.write() 的調用始終是成功。但是，如果操作系統內核緩沖區由于特殊的網絡錯誤而滿了的話，socket.write() 也會進入等待狀態。這種情況下，操作系統會嘗試重新發送數據包一段時間，并在達到超時限制時產生錯誤。
最后列出以下重點：
建議研發需要配置的超時包括：
sqlMap里的全局jdbcTimeout。視場景在sqlMap文件里單個語句中也可以設的jdbcTimeout，優先級高于全局的。針對MySql驅動在jboss控制臺配置JDBC URL后面加connectTimeout，socketTimeout，但需要保證比Statemant級別的超時設置要長。數據庫層面的wait_timeout建議半小時容器里需要注意配取數據連接的驗證，如下圖：pos機連接超時怎么辦
通常是網絡信號的問題，一般出現這種情況就是機器里面的sim卡賣卜么有流量了，你可以嘗試換一張自己的卡，移動或者聯通，帶有GPRS流量的卡，爛配皮放進去然后重啟一饑差下機器試試，如果還是不行清聯系服務商進行更換專用SIM卡。不懂可以咨詢
簡述tcp擁塞避免算法的工作過程？
1、慢開始和擁塞避免
基于窗口的擁塞控制，在發送方維護一個擁塞窗口（cwnd），大小等于發送窗口，通過出現了超時來判斷網絡出現擁塞。慢開始的思路是一開始發送方發送一個字節，在收到接收方的確認，然后發送的字節數量增大一倍（也就是按照指數增長的速率），從小到大逐步增大cwnd，直到cwnd 達到慢開始門限（ssthresh），停止慢開始算法，使用擁塞避免算法，擁塞避免算法思路是增長速率變為線性增長，也就是每經過一個往返時間RTT就把發送方的cwnd加1，所以綜上：
當cwnd < ssthresh ，使用慢開始算法；
當cwnd = ssthresh，可以使用慢開始算法，也可以使用擁塞算法；
當cwnd > ssthresh，使用擁塞算法；
2、快重傳和快恢復
通過上面兩個算法可以使得網絡傳輸速率一直增大，直到出現超時，這時候需要將cwnd重新調整到1個字節開始，使用慢開始算法，同時需要將慢開始門限ssthresh調整為cwnd（超時點）的一半，繼續執行慢開始、擁塞避免算法。如果收到3-ACK（發送方一連接收到3個對同一個報文段的重復確認），這種可能的情況是，并不是發生了擁塞，可能是報文丟失，所以發送方不執行慢開始算法，直接使用快重傳算法，立即發送缺失的報文段。同時執行快恢復算法，將門限值（ssthresh）調整為此時cwnd的一半，并執行擁塞避免算法。
以上就是關于pos機器tcp超時,深入了解JDBC超時機制的知識，后面我們會繼續為大家整理關于pos機器tcp超時的知識，希望能夠幫助到大家！
