3 回答

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

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