我的项目是ibatis+struts2+spring,项目在部署测试环境时,发现CUP占用很快达到100%。根据项目中的开发情况,将问题定位在几个定时执行的任务上面。一个个排除,最终找到了问题所在。
出问题了的程序在执行中调用了一个存储过程,该存储过程有两个返回参数具体程序如下:
1>ibatis配置文件:
<parameterMap id="backAwardMap" class="java.util.HashMap">
<parameter property="resultValue" mode="OUT" jdbcType="VARCHAR" javaType="java.lang.String"/>
<parameter property="v_errmsg" mode="OUT" jdbcType="VARCHAR" javaType="java.lang.String"/>
</parameterMap>
<procedure id="callBackAward" parameterMap="backAwardMap">
{call pro_lottery_backaward(?,?)}
</procedure>
</sqlMap>
2>dao:
public void executeBackAward(Map map) {
getSqlMapClientTemplate().queryForObject("callBackAward",map);
}
进过对比,发现这个存储过程的调用有所不同,使用了queryForObject方法,原意是该执行不需要控制事务。不必调用insert或者update方法。将上述调用修改成:
public void executeBackAward(Map map) {
getSqlMapClientTemplate().update("callBackAward",map);
}
部署后,运行一天再也没有出现CUP被过高占用的情况。到此问题得到解决。
出问题了的程序在执行中调用了一个存储过程,该存储过程有两个返回参数具体程序如下:
1>ibatis配置文件:
<parameterMap id="backAwardMap" class="java.util.HashMap">
<parameter property="resultValue" mode="OUT" jdbcType="VARCHAR" javaType="java.lang.String"/>
<parameter property="v_errmsg" mode="OUT" jdbcType="VARCHAR" javaType="java.lang.String"/>
</parameterMap>
<procedure id="callBackAward" parameterMap="backAwardMap">
{call pro_lottery_backaward(?,?)}
</procedure>
</sqlMap>
2>dao:
public void executeBackAward(Map map) {
getSqlMapClientTemplate().queryForObject("callBackAward",map);
}
进过对比,发现这个存储过程的调用有所不同,使用了queryForObject方法,原意是该执行不需要控制事务。不必调用insert或者update方法。将上述调用修改成:
public void executeBackAward(Map map) {
getSqlMapClientTemplate().update("callBackAward",map);
}
部署后,运行一天再也没有出现CUP被过高占用的情况。到此问题得到解决。