网上有很多关于pos机器tcp超时,深入了解JDBC超时机制的知识，也有很多人为大家解答关于pos机器tcp超时的问题，今天pos机之家(www.poszjia.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超时的知识，希望能够帮助到大家！
