3 回答

TA貢獻1784條經(jīng)驗 獲得超7個贊
所有數(shù)據(jù)庫語句都在物理事務(wù)的上下文中執(zhí)行,即使我們沒有顯式聲明事務(wù)邊界(BEGIN / COMMIT / ROLLBACK)也是如此。
如果您未明確聲明事務(wù)邊界,則每個語句將必須在單獨的事務(wù)(autocommit模式)中執(zhí)行。除非您的環(huán)境無法處理每線程連接綁定,否則這甚至可能導(dǎo)致每個語句打開和關(guān)閉一個連接。
將服務(wù)聲明為as @Transactional將在整個事務(wù)期間為您提供一個連接,并且所有語句將使用該單個隔離連接。這比首先不使用顯式事務(wù)更好。
在大型應(yīng)用程序上,您可能有許多并發(fā)請求,降低數(shù)據(jù)庫連接獲取請求率肯定會提高整體應(yīng)用程序性能。
JPA不會對讀取操作強制執(zhí)行事務(wù)。只有在您忘記啟動事務(wù)上下文的情況下,寫操作才會引發(fā)事務(wù)必需的異常。但是,即使對于只讀事務(wù),也最好聲明事務(wù)邊界(在Spring中@Transactional,您可以標(biāo)記只讀事務(wù),這具有很大的性能優(yōu)勢)。

TA貢獻1794條經(jīng)驗 獲得超8個贊
事務(wù)確實在數(shù)據(jù)庫上加了鎖-好的數(shù)據(jù)庫引擎以一種明智的方式處理并發(fā)鎖-并且對于只讀使用很有用,以確保沒有其他事務(wù)添加任何會使您的視圖不一致的數(shù)據(jù)。您總是想要一個事務(wù)(盡管有時調(diào)整隔離級別是合理的,但是最好不要這樣做)。如果您在事務(wù)期間從不向數(shù)據(jù)庫寫入數(shù)據(jù),則提交和回滾事務(wù)的結(jié)果是相同的(而且非常便宜)。
現(xiàn)在,如果您很幸運,并且對數(shù)據(jù)庫的查詢使得ORM始終將它們映射到單個SQL查詢,則可以依靠數(shù)據(jù)庫的內(nèi)置自動提交行為而無需顯式事務(wù)就可以逃脫,但是ORM是相對復(fù)雜的系統(tǒng)因此,依靠這種行為是絕對不安全的,除非您去做更多的工作來檢查實現(xiàn)的實際作用。在其中編寫明確的事務(wù)邊界要容易得多(特別是如果您可以使用AOP或一些類似的ORM驅(qū)動的技術(shù)來做到這一點;我想從Java 7開始,也可以使用try-with-resources)。
添加回答
舉報