线上一个mysql死锁问题

2016年7月8日，周五，本来一个欢快的日子，大家准备去吃会火锅唱会歌，下班前DBA同学发现突然有几个更新语句在query中，一直无法执行完，更新的语句基本是针对同一条更新的，语句的大概意思就是在交易完成后更新一条出库的记录，对已售数字进行加一，称之为SQLA；
分析开始
1.这个表很小，大概300条，执行sql中有索引，应该很快就执行完成，并且这段代码已经在线上安然度过半年多，先排除代码问题，转向是否被攻击
2.线上服务器对于交易接口进行了监控，请求数量很少，和阻塞的数量基本保持一致
3.再回到代码分析，交易目前是一个比较大的事务，事务中包含了：资产扣除，商品出库，第三方API（流量商品）发起订单请求并等待响应。整体操作中只有更新商品的兑换数量也就是SQLA会发生行锁的问题。
那么对于同一个商品品项如果事务A中SQLA之后的某个地方发生等待或阻塞，导致事务A无法完成，一直持有SQLA当时执行的行锁， 如图

[/img]

截至目前，应该可以定位到第一个问题，大量SQLA阻塞的问题，同一个商品交易，有一个事务存没有及时完成，导致此商品兑换一直处于阻塞的状态，而且根据mysql的特性，SQLA执行的表会拖慢整个数据库的性能。
那么是什么导致了某一个事务没有完成？大家的研究齐刷刷的看向了第三方API，会不会是这个玩意引起的，分别在再服务器日志中查看了一下这个api最近调用的日志记录，其中有一个线程，调用过之后一直没有再返回。。。。就这样默默的抛弃了我们，基本锁定是api的调用响应迟迟不来，导致整个事务无法结束，SQLA无法释放行锁，其他事务也不能完成，以此类推完成了这次晚上的超级大bug；

待解答问题：
1,api调用时通过java http 完成，超时默认应该是60秒，但是为什么没有超时需要进一步跟踪
2.api放在事务中确实需要剥离，具体方案稍后更新