老項(xiàng)目加新功能,導(dǎo)致出現(xiàn)service調(diào)用service的情況..一共2張表有數(shù)據(jù)的添加刪除.然后測試了一下事務(wù),表A和表B,我在表B中拋了異常,但結(jié)果發(fā)現(xiàn),表B回滾正常,但是表A并沒有回滾.顯示事務(wù)失效.

比較巧的是表A和表B是在不同的service中,所以最開始想到的是多service導(dǎo)致的,但是查看了事務(wù)的定義后發(fā)現(xiàn),事務(wù)的傳播被設(shè)置成required,所以按理說所有service會(huì)處在一個(gè)事務(wù)中.經(jīng)過痛苦的各種折騰各種嘗試未果后,無意中發(fā)現(xiàn)每次都是表A事務(wù)無法回滾,這就有點(diǎn)奇怪了,這明顯就是操作表A的事務(wù)失效了.其實(shí)這里我已經(jīng)非常接近真正的原因了,只不過我依然認(rèn)為可能是自己的錯(cuò)誤配置導(dǎo)致操作表A的service事務(wù)失效,又是一陣折騰,實(shí)在看不出來有什么錯(cuò)誤的地方,有點(diǎn)無奈.

沒有什么思路,只好百度一下都有什么原因能導(dǎo)致事務(wù)失敗,看了一堆帖子,無意中看到一個(gè)情況,mysql引擎導(dǎo)致的事務(wù)失效,瞬間一下都明白了..

找到表A的定義語句末尾能看到如下:

ENGINE=MyISAM AUTO_INCREMENT=40 DEFAULT CHARSET=gbk

稍微百度一下就能知道,mysql的MyISAM引擎是不支持事務(wù)的,所以想要支持事務(wù),必須選擇InnoDB引擎,將表A的mysql引擎改成InnoDB后,一切恢復(fù)正常.

感想:事務(wù)失效第一印象一定是各種配置或是代碼的錯(cuò)誤,但是看似無害的數(shù)據(jù)庫可能才是隱藏在背后的罪魁禍?zhǔn)?.