將會話在休眠轉換爲plein JDBC連接

Question

我正在從休眠轉換回普通JDBC，以克服使用hibernate引起的開銷。我想知道如何處理與hibernate相關的會話。如何轉換回到普通的JDBC，以便我的所有會話都被JDBC連接替換。請讓我知道如果我錯在我的想法中，用連接替換會話會轉換回普通JDBC，因爲我對這些概念並不熟悉，並且不會知道我是否以正確的方式進行。

Answer 1

我在高性能任務中廣泛使用了Hibernate，包括批量插入數百萬條記錄。你的問題不在於Hibernate，而在於你使用它的方式。

最重要的是，不要將Hibernate用作持久狀態管理器;將它用作原始SQL之上的薄層，並且您不會抱怨性能。

1. 總是喜歡StatelessSession（它爲你工作需要，除了save操作一切）`;
2. 從來沒有使用懶惰抓取，使用顯式連接for eachthng;
3. 永遠不會獲取整個對象，使用SELECT來獲取你需要的東西;
4. 儘可能在單個語句中獲取，不惜一切代價避免n + 1個選項;
5. 大結果集，從不使用list，使用iterate或scroll。

這個名單還在繼續，但這是我現在想到的。

至於你的直接問題，它取決於應用程序。如果它是一個Spring應用程序，那麼你一定會想要使用它的聲明式事務管理。基本上，您只需放幾行XML配置，並且您的DAO代碼中將有一個開放的DataSource可供使用，無需您管理。

如果你正在做更多的事情，那麼一定要使用連接池庫，比如偉大的BoneCP。你從它那裏獲得連接，然後返回到它，再次沒有明確的管理。最後，如果你真的想要一個簡單的，不安全的和不可擴展的方法，那麼你可以直接從JDBC驅動創建連接。這種方法實際上只適用於功課，即使在最小的有生產價值的項目中也不推薦。

Answer 2

Hibernate會話不僅僅是JDBC連接。它包含多個這樣的連接（通常通過一個JDBC連接池進行管理，該連接池可以回收JDBC連接實例），附加到所述會話以及由所述會話管理的一組實體以及其他事物（緩存等）。

刪除Hibernate並使用JDBC API進行所有操作僅僅意味着用一個或多個JDBC連接替換Hibernate Session實例，然後將Hibernate代碼複製到類似的JDBC API調用中。如果你只是這麼做的話，那麼你只需要做很多工作就可以了，因爲你會失去Hibernate的所有優點（代碼冗長，抽象程度更高等），並且不會獲得JDBC的優勢（更少堆內存的使用，更少的方法調用（是的，即使使用Hibernate的Javassist魔術，這在某些情況下仍然會影響性能），更好地控制數據庫交互等等。

我的建議是首先真正地研究你的應用程序所具有的問題（顯然是由於Hibernate），並且至少對於主要的問題，首先嚐試先看看你是否無法在不擺脫Hibernate的情況下對其進行優化。是的，Hibernate可能會變得沉重和內存飢渴，但是更多的時候，性能問題來自於對框架的不正確使用（你確定你在一個查詢中獲取所有必要的關聯實體，或者你是否讓Hibernate創建在後臺隱藏連接或僞連接？您是在數據庫端執行數據操作嗎，還是在執行了一個非必要泛型Hibernate查詢以獲取數據之後在Java代碼中完成的某些操作？等等）

如果你真的需要擺脫Hibernate（也許你需要使用一些非標準的SQL特定功能，而Hibernate不允許你訪問，比如MySQL能夠導入大量的數據通過自定義的平面文件格式），然後確保你將它替換爲什麼（普通的JDBC，或者其他一些像EclipseLink這樣的ORM）可以用tac解決問題並以更高效的方式解決問題。在開始重新使用代碼之前，做一個小的POC來測試這些代碼可以爲您節省大量時間。

Answer 3

雖然我強烈建議您留意Marko和Shivan的建議，但可以使用hibernate來管理連接/會話/事務，並執行SQL查詢，而不會產生大量開銷。

一個快速的谷歌搜索取得了這個從休眠會話執行SQL。

http://www.informit.com/guides/content.aspx?g=java&seqNum=575

雖然我與兩個早期的答案基本一致，如果你真的想下去執行直接的SQL的路，我會考慮這個選項有兩個原因。

1）您的會議已經到位。如果你沒有休眠加載你所有的實體，我不會看到hibernate會如何產生這麼多的開銷。

2）如果問題是速度問題，而不是我之前遇到的開銷問題，那麼可以實現這個功能，以便在問題區域中快速執行本機SQL，並保留所有休眠狀態的ORM好東西。

所有這一切，我還敦促你深入瞭解hibernate的文檔。我已經使用hibernate獲得了很多高性能解決方案，並取得了巨大成功儘管這些細微差別在開始時可能很難解決，但使用hibernate（或者至少符合JPA標準的東西）的好處遠遠超過了不這樣做的道路可擴展性的成本。