Posted on 2009-08-21 16:52
寒武纪 阅读(4310)
评论(24) 编辑 收藏 所属分类:
心得
最近的二个项目,由于规模较小,都是十张表之内,而且表关联非常少。所以用了一下iBatis做为数据库关系映射,本着减少手写JDBC代码的目的,想着可以减少工作量。但是却遇到了二个令人郁闷的问题。由于环境的限制,使用了jdk1.4.x编译的iBatis2.3版本,没有使用最近的。
第一问题: 其中的一个项目,有一个表为它配置了sql Map的一个delete操作,非常简单,大概就是delete from xxx where id=#value#这样的语句,然后用sqlMapClient进行操作,日志打印完全正常,没有报任何Exception,返回影响记录数也是正确的。但是进数据库一看,巍然不动!左查查,右查查,查不出任何毛病。更奇怪的是,数据库表之间的所有关联和索引全部取消,还是存在这问题。其它的三个字段比较少的表,这样配置,同样的api调用却正常!这个出问题的数据库表字段大概20+个左右。
第二个问题:另一个项目,是二期重构,本来一期也不复杂,全部是使用JDBC实现的,只是有些表的字段太多,JDBC写到烦,特别是处理一些NULL的插入,还有批处理时异常日志的详细处理也有点烦。近期做二期升级,就算采用iBatis来减少一些代码量,于于喜涮涮地搞上去了,代码的确减少了许多。单元测试也能通过,后来就设置了比较复杂的数据。发现问题的现场如下:在一个业务接口中,一个事务中包含了许多SQL操作,有delete,也有insert,大概十个sql语句左右,全部放在一个batch中执行,整个batch提交一个事务。测试环境提供了31个类似的业务数据,总共执行31个事务,采用for的循环执行调用,每逢索引 i = 10*n 的时候就会卡住,这个操作得花很长时间,最后能通过。后来进行跟踪,发现是在执行第一个语句delete一个记录(delete from xxx where id='xx')同样也是单表删除。搜索了google,baidu,没有任何资源,翻遍了文档没有任何说明,查了网站FAQ也没有办法。于是,只能.......郁闷!
为什么遇到delete都会有这个问题?不晓得有没有高手遇到同样的问题,这里算是总结的同时也提问,希望有遇到相同类型的高手给个解决的方案。如果不行,就得倒回去用JDBC实现,就此iBatis的体验使用也就搁置,估计以后也不会碰它了。Hibernate就不用了,有点小题大作。
google了才知道,原来iBatis的书籍、论坛、资料、讨论等等相比Hibernate要少很多。学习是很简单,但是遇到这种细节的时候,又不太愿意花时间去研究源代码(都是现实所逼,有个球时间呀?)。所以选框架要慎重!!!
刚进场的时候戏就落幕
Feedback
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-21 17:06 by
应该是没有设置好。用过,但没有出现这个问题。
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-21 17:08 by
事先没搞好调查
# re: 无奈只能放弃iBatis[未登录] 回复 更多评论
2009-08-21 17:20 by
不会这么惨吧
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-21 17:28 by
不是吧
# re: 无奈只能放弃iBatis[未登录] 回复 更多评论
2009-08-21 17:45 by
其实读源码才是最省时间的方法。
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-21 17:49 by
看看ibatis的源码不就知道了 自己跟踪一下 把源码包弄到你们的工程里面去
# re: 无奈只能放弃iBatis[未登录] 回复 更多评论
2009-08-21 20:30 by
Ibatis也很无奈~
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-21 20:58 by
简单 google 查不到,开源的东西,源码都明摆着,留着源码不看,楞着头想还不大大的浪费时间吗!
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-21 22:04 by
要成为高手,就得看源代码。
# re: 无奈只能放弃iBatis[未登录] 回复 更多评论
2009-08-22 08:35 by
ibatis的相关资料是少,不过jdbc的资料虽然多,但是也有很多疑难杂症会让人束手无策。
也不能指望人人都去看源码,且人人都看得懂源码。
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-22 09:31 by
不太可能是iBatis的问题,iBatis不过充当了一个集中SQL管理的地方,增删查改还是靠jdbc实现的啊。我公司的产品几百张表,几十个字段的表多得是,从来也没出现过你这种问题。建议你还是从数据库、还有事务处理着手,看看是不是设计本身的问题。
# re: 无奈只能放弃iBatis[未登录] 回复 更多评论
2009-08-22 20:56 by
一看就知道是事务的问题了,你用的是什么数据库,你配置事务了吗
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-22 21:44 by
事先没搞好调查
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-23 19:42 by
IBATIS大喊冤枉,这么简单的框架都用不好:(
# re: 无奈只能放弃iBatis[未登录] 回复 更多评论
2009-08-24 09:53 by
没遇到过类似楼主所说的问题,我想可能是配置有问题吧。
iBATIS还是挺简单的一个框架,楼主多多研究一下吧。
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-24 10:47 by
不去学习源代码,永远都是菜鸟
碰到问题就放弃,还是菜鸟
你这样发展下去,就是菜鸟
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-24 17:41 by
是不是和数据库事务设置有关系,我们也用ibatis的框架,一个批处理几千万的数据没有出现这种情况。
我觉得ibatis还是很好的一个框架,手写的SQL比较放心些。
# re: 无奈只能放弃iBatis[未登录] 回复 更多评论
2009-08-24 21:18 by
没有任何根据的胡乱猜测。。手写的sql才放心。。
# re: 无奈只能放弃iBatis 回复 更多评论
2009-08-25 11:35 by
我想肯定是lz用错了, 我们项目一直都用的是ibaties ,都几年了。 目前没出现任何不能解决的问题. 仔细找找,切勿因此而影响对iBATIS的看法
# re: 无奈只能放弃iBatis 回复 更多评论
2009-10-11 22:19 by
可能是跟事务没提交有关
# re: 无奈只能放弃iBatis 回复 更多评论
2009-11-01 18:58 by
ibatis的确很傻b,用的人更傻b。
# re: 无奈只能放弃iBatis 回复 更多评论
2010-08-16 08:56 by
有没有在最后执行 session.commit()?
# re: 无奈只能放弃iBatis 回复 更多评论
2011-03-18 18:39 by
哥们现在回头再看看这篇文章,觉得还是ibatis的问题吗?
# re: 无奈只能放弃iBatis 回复 更多评论
2012-05-16 11:38 by
ibatis一直在用,没有那样的问题