最近学习测试mybatis,单个增删改查都没问题,最后使用mvn test的时候发现了几个问题:
1.update失败,原因是数据库死锁
2.select等待,原因是connection连接池被用光了,需要等待
get:
1.要勇于探索,坚持就是胜利。刚看到错误的时候直接懵逼,因为错误完全看不出来,属于框架内部报错,在犹豫是不是直接睡
觉得了,毕竟也快12点了。最后还是给我一点点找到问题所在了。
2.同上,要敢于去深入你不了解的代码,敢于研究不懂的代码。
3.距离一个合格的码农越来越远了,因为越学越觉得漏洞百出,自己的代码到处都是坑。所以,一定要记录下来。
下面记录这两个问题。
1.mysql数据库死锁
这里,感谢http://www.cnblogs.com/lin-xuan/p/5280614.html,我找到了答案。在这里,我还是重现一下:
数据库死锁是事务性数据库 (如SQL Server, MySql等)经常遇到的问题。除非数据库死锁问题频繁出现导致用户无法操作,一般情况下数据库死锁问题不严重。在应用程序中进行try-catch就可以。那么数据死锁是如何产生的呢?
InnoDB实现的是行锁 (row level lock),分为共享锁 (S) 和 互斥锁 (X)。
•共享锁用于事务read一行。
•互斥锁用于事务update或delete一行。
当客户A持有共享锁S,并请求互斥锁X;同时客户B持有互斥锁X,并请求共享锁S。以上情况,会发生数据库死锁。如果还不够清楚,请看下面的例子。
双开两个mysql客户端
客户端A:
开启事务,并锁定共享锁S 在id=12的时候:
mysql> START TRANSACTION; Query OK, 0 rows affected (0.00 sec) mysql> SELECT * FROM blog WHERE id = 12 LOCK IN SHARE MODE; +----+-------+-----------+ | id | name | author_id | +----+-------+-----------+ | 12 | testA | 50 | +----+-------+-----------+ 1 row in set (0.00 sec)
客户端B:
开启事务,尝试删除id=12:
mysql> START TRANSACTION; Query OK, 0 rows affected (0.00 sec) mysql> DELETE FROM blog WHERE id = 12;
删除操作需要互斥锁 (X),但是互斥锁X和共享锁S是不能相容的。所以删除事务被放到锁请求队列中,客户B阻塞。
这时候客户端A也想要删除12:
mysql> DELETE FROM blog WHERE id = 12; Query OK, 1 row affected (0.00 sec)
和参考文章不同的是,居然删除成功了,但客户端B出错了:
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
于是,我尝试删除13,这下都阻塞了:
我的mybatis测试代码中,因为上一个测试没有commit导致死锁,commit后就ok了。在这里,我想说,数据库的东西全还给老师了,关于锁以及事务需要重新温习一下了。
2.Mybatis中datasource的数据库连接数
当我mvn test的时候,我发现有个查询的test打印日志:
2016-07-21 23:43:53,356 DEBUG [org.apache.ibatis.transaction.jdbc.JdbcTransaction] - Opening JDBC Connection
2016-07-21 23:43:53,356 DEBUG [org.apache.ibatis.datasource.pooled.PooledDataSource] - Waiting as long as 20000 milliseconds for connection.
于是,果然等了一段时间后才执行成功。跟踪源码,找到这处日志就明白了。首先,我这里使用的数据库连接配置是mybatis默认的:
<environment id="development"> <transactionManager type="JDBC"/> <dataSource type="POOLED"> <property name="driver" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </dataSource> </environment> 当数据库连接池的连接数用光了之后就要等2s再去获取: while (conn == null) { synchronized (state) { if (!state.idleConnections.isEmpty()) { // Pool has available connection conn = state.idleConnections.remove(0); if (log.isDebugEnabled()) { log.debug("Checked out connection " + conn.getRealHashCode() + " from pool."); } } else { // Pool does not have available connection if (state.activeConnections.size() < poolMaximumActiveConnections) { // Can create new connection conn = new PooledConnection(dataSource.getConnection(), this); if (log.isDebugEnabled()) { log.debug("Created connection " + conn.getRealHashCode() + "."); } } else { // Cannot create new connection PooledConnection oldestActiveConnection = state.activeConnections.get(0); long longestCheckoutTime = oldestActiveConnection.getCheckoutTime(); if (longestCheckoutTime > poolMaximumCheckoutTime) { // Can claim overdue connection state.claimedOverdueConnectionCount++; state.accumulatedCheckoutTimeOfOverdueConnections += longestCheckoutTime; state.accumulatedCheckoutTime += longestCheckoutTime; state.activeConnections.remove(oldestActiveConnection); if (!oldestActiveConnection.getRealConnection().getAutoCommit()) { try { oldestActiveConnection.getRealConnection().rollback(); } catch (SQLException e) { log.debug("Bad connection. Could not roll back"); } } conn = new PooledConnection(oldestActiveConnection.getRealConnection(), this); oldestActiveConnection.invalidate(); if (log.isDebugEnabled()) { log.debug("Claimed overdue connection " + conn.getRealHashCode() + "."); } } else { // Must wait try { if (!countedWait) { state.hadToWaitCount++; countedWait = true; } if (log.isDebugEnabled()) { log.debug("Waiting as long as " + poolTimeToWait + " milliseconds for connection."); } long wt = System.currentTimeMillis(); state.wait(poolTimeToWait); state.accumulatedWaitTime += System.currentTimeMillis() - wt; } catch (InterruptedException e) { break; } } } } if (conn != null) { if (conn.isValid()) { if (!conn.getRealConnection().getAutoCommit()) { conn.getRealConnection().rollback(); } conn.setConnectionTypeCode(assembleConnectionTypeCode(dataSource.getUrl(), username, password)); conn.setCheckoutTimestamp(System.currentTimeMillis()); conn.setLastUsedTimestamp(System.currentTimeMillis()); state.activeConnections.add(conn); state.requestCount++; state.accumulatedRequestTime += System.currentTimeMillis() - t; } else { if (log.isDebugEnabled()) { log.debug("A bad connection (" + conn.getRealHashCode() + ") was returned from the pool, getting another connection."); } state.badConnectionCount++; localBadConnectionCount++; conn = null; if (localBadConnectionCount > (poolMaximumIdleConnections + 3)) { if (log.isDebugEnabled()) { log.debug("PooledDataSource: Could not get a good connection to the database."); } throw new SQLException("PooledDataSource: Could not get a good connection to the database."); } } } } }
当连接数少于10个的时候回创建,超过10个就会等待,不然就报错。
以上所述是小编给大家介绍的Mybatis update数据库死锁之获取数据库连接池等待,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对小牛知识库网站的支持!
null 提前谢了。
我在应用程序中使用连接池(snaq.db.ConnectionPool)。连接池的初始化方式如下: 使用的DB池值是: 我的应用程序在某处泄漏连接(连接未被释放),因此连接池已耗尽。我现在已经修好了密码。 空闲超时后连接不应该关闭吗?如果这不是正确的假设,有没有办法关闭打开的空闲连接(仅通过java代码)?
我正在为员工管理系统创建一个web应用程序,使用ApacheTomcat作为HTTP服务器,Oracle作为数据库,applet用于客户端编程,servlet用于服务器端编程。我还想使用DBCP来管理与数据库的连接。 我希望执行查询的servlet使用客户端为连接输入的用户名和密码。但是到目前为止,我看到在中配置资源时必须设置连接池的用户名和密码。 有没有什么方法可以实现这一点并且仍然使用DBCP
由于基于HTTP协议的Web程序是无状态的,因此,在应用程序中使用JDBC时,每次处理客户端请求时都会重新建立数据库连接。如果客户端的请求非常频繁,服务端在处理数据库时将会消耗非常多的资源。因此,在Tomcat中提供了数据库连接池技术。数据库连接池负责分配、管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而不是重新建立一个数据库连接。在使用完一个数据库连接后,将其归还数据库连接池
本文向大家介绍JDBC如何获取数据库连接,包括了JDBC如何获取数据库连接的使用技巧和注意事项,需要的朋友参考一下 JDBC(Java Database Connectivity),即Java数据库连接。通过JDBC编程,可以使Java应用程序和数据库进行交互。 JDBC驱动的方式有很多种,我们常用的驱动方式为:本地协议的纯Java驱动程序。 JDBC编程的第一步,就是要获取数据库连接。所谓的 “
问题内容: 某些数据库功能(例如和)很容易受到死锁的影响,因为数据库未指定将使用哪种锁定顺序。我发现有两次 讨论暗示此行为不是SQL标准指定的,更不用说具体的实现了。因此,我在假设我们无法控制锁定顺序的情况下进行操作(至少,这样做并不明显)。 如果我们不能依赖锁定顺序,应该如何避免数据库死锁? 如果我们不应该避免僵局(您将不得不非常努力地说服我),那么我们应该怎么做? 这个问题与数据库无关,所以请