nighty

    最近的二個項目，由于規(guī)模較小，都是十張表之內(nèi)，而且表關(guān)聯(lián)非常少。所以用了一下iBatis做為數(shù)據(jù)庫關(guān)系映射，本著減少手寫JDBC代碼的目的，想著可以減少工作量。但是卻遇到了二個令人郁悶的問題。由于環(huán)境的限制，使用了jdk1.4.x編譯的iBatis2.3版本，沒有使用最近的。

    第一問題：  其中的一個項目，有一個表為它配置了sql Map的一個delete操作，非常簡單，大概就是delete from xxx where id=#value#這樣的語句，然后用sqlMapClient進行操作，日志打印完全正常，沒有報任何Exception，返回影響記錄數(shù)也是正確的。但是進數(shù)據(jù)庫一看，巍然不動！左查查，右查查，查不出任何毛病。更奇怪的是，數(shù)據(jù)庫表之間的所有關(guān)聯(lián)和索引全部取消，還是存在這問題。其它的三個字段比較少的表，這樣配置，同樣的api調(diào)用卻正常！這個出問題的數(shù)據(jù)庫表字段大概20+個左右。

    第二個問題：另一個項目，是二期重構(gòu)，本來一期也不復(fù)雜，全部是使用JDBC實現(xiàn)的，只是有些表的字段太多，JDBC寫到煩，特別是處理一些NULL的插入，還有批處理時異常日志的詳細處理也有點煩。近期做二期升級，就算采用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  的時候就會卡住，這個操作得花很長時間，最后能通過。后來進行跟蹤，發(fā)現(xiàn)是在執(zhí)行第一個語句delete一個記錄（delete from xxx where id='xx'）同樣也是單表刪除。搜索了google，baidu，沒有任何資源，翻遍了文檔沒有任何說明，查了網(wǎng)站FAQ也沒有辦法。于是，只能.......郁悶!

   為什么遇到delete都會有這個問題？不曉得有沒有高手遇到同樣的問題，這里算是總結(jié)的同時也提問，希望有遇到相同類型的高手給個解決的方案。如果不行，就得倒回去用JDBC實現(xiàn)，就此iBatis的體驗使用也就擱置，估計以后也不會碰它了。Hibernate就不用了，有點小題大作。
   google了才知道，原來iBatis的書籍、論壇、資料、討論等等相比Hibernate要少很多。學(xué)習(xí)是很簡單，但是遇到這種細節(jié)的時候，又不太愿意花時間去研究源代碼（都是現(xiàn)實所逼，有個球時間呀？）。所以選框架要慎重！！！

剛進場的時候戲就落幕