Posted on 2009-08-21 16:52
寒武紀(jì) 閱讀(4324)
評論(24) 編輯 收藏 所屬分類:
心得
最近的二個項(xiàng)目,由于規(guī)模較小,都是十張表之內(nèi),而且表關(guān)聯(lián)非常少。所以用了一下iBatis做為數(shù)據(jù)庫關(guān)系映射,本著減少手寫JDBC代碼的目的,想著可以減少工作量。但是卻遇到了二個令人郁悶的問題。由于環(huán)境的限制,使用了jdk1.4.x編譯的iBatis2.3版本,沒有使用最近的。
第一問題: 其中的一個項(xiàng)目,有一個表為它配置了sql Map的一個delete操作,非常簡單,大概就是delete from xxx where id=#value#這樣的語句,然后用sqlMapClient進(jìn)行操作,日志打印完全正常,沒有報任何Exception,返回影響記錄數(shù)也是正確的。但是進(jìn)數(shù)據(jù)庫一看,巍然不動!左查查,右查查,查不出任何毛病。更奇怪的是,數(shù)據(jù)庫表之間的所有關(guān)聯(lián)和索引全部取消,還是存在這問題。其它的三個字段比較少的表,這樣配置,同樣的api調(diào)用卻正常!這個出問題的數(shù)據(jù)庫表字段大概20+個左右。
第二個問題:另一個項(xiàng)目,是二期重構(gòu),本來一期也不復(fù)雜,全部是使用JDBC實(shí)現(xiàn)的,只是有些表的字段太多,JDBC寫到煩,特別是處理一些NULL的插入,還有批處理時異常日志的詳細(xì)處理也有點(diǎn)煩。近期做二期升級,就算采用iBatis來減少一些代碼量,于于喜涮涮地搞上去了,代碼的確減少了許多。單元測試也能通過,后來就設(shè)置了比較復(fù)雜的數(shù)據(jù)。發(fā)現(xiàn)問題的現(xiàn)場如下:在一個業(yè)務(wù)接口中,一個事務(wù)中包含了許多SQL操作,有delete,也有insert,大概十個sql語句左右,全部放在一個batch中執(zhí)行,整個batch提交一個事務(wù)。測試環(huán)境提供了31個類似的業(yè)務(wù)數(shù)據(jù),總共執(zhí)行31個事務(wù),采用for的循環(huán)執(zhí)行調(diào)用,每逢索引 i = 10*n 的時候就會卡住,這個操作得花很長時間,最后能通過。后來進(jìn)行跟蹤,發(fā)現(xiàn)是在執(zhí)行第一個語句delete一個記錄(delete from xxx where id='xx')同樣也是單表刪除。搜索了google,baidu,沒有任何資源,翻遍了文檔沒有任何說明,查了網(wǎng)站FAQ也沒有辦法。于是,只能.......郁悶!
為什么遇到delete都會有這個問題?不曉得有沒有高手遇到同樣的問題,這里算是總結(jié)的同時也提問,希望有遇到相同類型的高手給個解決的方案。如果不行,就得倒回去用JDBC實(shí)現(xiàn),就此iBatis的體驗(yàn)使用也就擱置,估計(jì)以后也不會碰它了。Hibernate就不用了,有點(diǎn)小題大作。
google了才知道,原來iBatis的書籍、論壇、資料、討論等等相比Hibernate要少很多。學(xué)習(xí)是很簡單,但是遇到這種細(xì)節(jié)的時候,又不太愿意花時間去研究源代碼(都是現(xiàn)實(shí)所逼,有個球時間呀?)。所以選框架要慎重!!!
剛進(jìn)場的時候戲就落幕
Feedback
應(yīng)該是沒有設(shè)置好。用過,但沒有出現(xiàn)這個問題。
# re: 無奈只能放棄iBatis[未登錄] 回復(fù) 更多評論
2009-08-21 17:20 by
不會這么慘吧
# re: 無奈只能放棄iBatis[未登錄] 回復(fù) 更多評論
2009-08-21 17:45 by
其實(shí)讀源碼才是最省時間的方法。
看看ibatis的源碼不就知道了 自己跟蹤一下 把源碼包弄到你們的工程里面去
# re: 無奈只能放棄iBatis[未登錄] 回復(fù) 更多評論
2009-08-21 20:30 by
Ibatis也很無奈~
簡單 google 查不到,開源的東西,源碼都明擺著,留著源碼不看,楞著頭想還不大大的浪費(fèi)時間嗎!
# re: 無奈只能放棄iBatis[未登錄] 回復(fù) 更多評論
2009-08-22 08:35 by
ibatis的相關(guān)資料是少,不過jdbc的資料雖然多,但是也有很多疑難雜癥會讓人束手無策。
也不能指望人人都去看源碼,且人人都看得懂源碼。
不太可能是iBatis的問題,iBatis不過充當(dāng)了一個集中SQL管理的地方,增刪查改還是靠jdbc實(shí)現(xiàn)的啊。我公司的產(chǎn)品幾百張表,幾十個字段的表多得是,從來也沒出現(xiàn)過你這種問題。建議你還是從數(shù)據(jù)庫、還有事務(wù)處理著手,看看是不是設(shè)計(jì)本身的問題。
# re: 無奈只能放棄iBatis[未登錄] 回復(fù) 更多評論
2009-08-22 20:56 by
一看就知道是事務(wù)的問題了,你用的是什么數(shù)據(jù)庫,你配置事務(wù)了嗎
# re: 無奈只能放棄iBatis[未登錄] 回復(fù) 更多評論
2009-08-24 09:53 by
沒遇到過類似樓主所說的問題,我想可能是配置有問題吧。
iBATIS還是挺簡單的一個框架,樓主多多研究一下吧。
不去學(xué)習(xí)源代碼,永遠(yuǎn)都是菜鳥
碰到問題就放棄,還是菜鳥
你這樣發(fā)展下去,就是菜鳥
是不是和數(shù)據(jù)庫事務(wù)設(shè)置有關(guān)系,我們也用ibatis的框架,一個批處理幾千萬的數(shù)據(jù)沒有出現(xiàn)這種情況。
我覺得ibatis還是很好的一個框架,手寫的SQL比較放心些。
# re: 無奈只能放棄iBatis[未登錄] 回復(fù) 更多評論
2009-08-24 21:18 by
沒有任何根據(jù)的胡亂猜測。。手寫的sql才放心。。
我想肯定是lz用錯了, 我們項(xiàng)目一直都用的是ibaties ,都幾年了。 目前沒出現(xiàn)任何不能解決的問題. 仔細(xì)找找,切勿因此而影響對iBATIS的看法
有沒有在最后執(zhí)行 session.commit()?
哥們現(xiàn)在回頭再看看這篇文章,覺得還是ibatis的問題嗎?