Hibernate事務有多複雜

這可能更像是一個「設計」或樣式問題：我剛纔考慮過Hibernate事務應該或可能有多複雜。我正在使用一個使用Hibernate將消息保存到數據庫的應用程序。Hibernate事務有多複雜

構建消息POJO涉及將消息中的一對多關係分解爲各自的持久對象。例如，該消息包含「城市」字段。城市從消息中提取，數據庫搜索等效的城市對象，並將結果對象添加到消息POJO中。所有這一切都是在一個事務中完成：

開始交易
試驗重複
檢索城市對象
retreive國家物體
setCountry
setCity（cityObject）（countryObject）在消息對象
堅持消息對象
承諾結束交易

事實上，實際的交易是相當複雜的。這是一個合理的結構，還是應該在單個交易中完成每項任務（而不是一次交易中的所有任務）？我想第二個問題涉及在設計交易中的任務時的最佳實踐。我明白有些任務需要按照參照完整性進行分組，但事實並非總是如此。

來源

2012-06-14 skyman

無論你放在你的外部事務邊界內，問題是你是否可以成功地回滾每個動作。

在邊界內捆綁相關操作，並儘可能簡化操作。

來源

2012-06-14 12:39:11 opyate

我假設在設置和關閉交易時存在績效成本？我應該關注這個還是會在實際的數據庫操作的持續時間內造成影響？ – skyman

JDBC只會推遲到底層DB的事務機制。然後，您可以研究底層商店事務處理的空間/時間複雜性，以獲得更好的想法。我推測你使用MySQL，如果是的話，我推薦[InnoDB]（http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-model.html）。顯然，Hibernate，JDBC等等需要創建類，處理異常，當事務回滾時你的虛擬機需要收集垃圾等，這也是你可以測量的東西。 – opyate

應根據業務需求進行分組，而不是技術複雜性。如果你有N個操作必須成功或失敗，那麼這就是代碼應該支持的。它應該更多的是商業考慮因素，而不是技術因素。

來源

2012-06-14 12:38:15 duffymo

多個事務只有在DB之間沒有處於愚蠢的狀態時纔有意義，因爲任何單個事務都可能失敗。嵌套如果任何活動塊必須是原子的，並且整個事務取決於任何其他原子單元，則交易可能有意義。

來源

2012-06-14 12:41:19

因此，我可以合理地說，我給出的檢索城市和國家對象應該在單獨的事務中，然後第三個事務應該堅持消息對象？ – skyman

我不明白他們爲什麼需要分開交易;數據庫不會因讀取操作而處於不確定狀態。 –

感謝戴夫 - 我開始理解這一點。我想我實際上誤解了你之前的評論。 – skyman

Hibernate事務有多複雜

回答

相關問題