有沒有很好的理由不讓你的申請處理任何交易？

Question

爲什麼在代碼中沒有事務管理有什麼好的理由？

問題出現在與dba交談時，當我提出spring/hibernate時，dba非常緊張。我提到Spring可以處理事務，使用Hibernate將表映射到對象等，並且問題出現了，數據庫（Oracle10g）已經處理事務管理，所以我們應該使用它。他甚至提出了這樣的想法，即我們創建了一堆DB過程來執行插入/更新，以便數據庫可以更有效地處理事情，並返回0/1是否插入/更新工作。

有沒有很好的理由不讓你的應用程序處理任何交易？我的dba無能爲力嗎？我想他是，但是當我不確定答案時，我不是一個很好的演講者......這就是我尋找答案的原因。

Answer 1

我覺得這裏有一些誤解。

問題是數據庫不像Spring/Hibernate那樣管理事務。

數據庫通過提供事務行爲來「管理事務」，並且應用程序通過使用該行爲並定義事務邊界（特別是在Spring或Hibernate的幫助下）來「管理事務」。

由於事務的邊界由業務邏輯定義，所以在沒有事務管理的情況下實現應用程序將需要將所有業務邏輯移至數據庫端。即使作爲存儲過程實現簡單的插入/更新操作，只要應用程序需要定義應在同一事務內執行多個插入/更新，就不足以從事務管理中釋放應用程序。

Answer 2

我不完全確定是否意味着會有一堆crud存儲過程（即單個插入或更新），或者是否存在包含業務邏輯（事務腳本）的存儲過程。如果你的意思是糟糕的存儲過程，這是一個完全不好的主意。 （事實上​​，即使你開始使用crud方法，隨着業務邏輯的增加，你最終會得到交易腳本，所以它也是相同的事情。）如果你指的是交易腳本，這是一些地方採取的方法。這是痛苦的，沒有重用，最終你會得到一堆很難測試的非常複雜的存儲過程。但DBA喜歡它，因爲他們知道發生了什麼。

還有一個參數（適用於事務腳本），它的速度更快，因爲往返次數少，您有一次調用存儲過程並執行所有操作並返回結果，這與通常的Spring/Hibernate應用程序，你有多個查詢或更新，每個語句都通過網絡傳遞給數據庫（儘管Hibernate緩存和重新排序以儘量減少這種情況）。儘量減少網絡往返次數可能是此方法最有效的原因，您必須權衡是否值得犧牲靈活性來減少網絡流量，或者是否過早優化。

另一個支持事務腳本的觀點是，要正確實現系統需要較少的權限。特別是Hibernate的專業知識不是必需的。你可以僱傭一些代碼猴子，讓他們敲出代碼。所有困難的東西都從他們身上移除，置於DBA的控制之下。

因此，要回顧一下，這裏有交易腳本參數：

• 減少網絡流量

• 便宜開發商

• 總DBA控制（從您的角度來看，他將是一個總瓶頸）

Answer 3

就像我上面提到，沒有辦法從數據庫的角度來「使用交易」，而沒有讓你的應用程序知道它在的一些級別。儘管如果您使用的是Spring，通過使用<tx:annotation-driven>並將@Transactional註釋應用於服務實現類中的相關方法，可以使其非常輕鬆。

也就是說，有時您應該繞過事務並直接寫入數據庫。特別是任何時候，速度比保證數據完整性更重要。