關於download項目的一點總結

背景

    網站有不少table提供download all的功能，簡單來講就是能將table的所有數據以CSV的文件形式發送到客戶的註冊郵箱。動輒幾千萬的數據量註定這個功能不適合在前臺Tomcat中完成，因此纔有一個單獨的項目負責處理客戶的請求，以隊列形式完成客戶請求。

    這個功能以前和後臺的項目是整合在一塊兒的， 主要作法是把前臺的DAO等邏輯複製到後臺，經過讀取客戶提交的參數模擬和前臺同樣的查詢，最後的出結果發送給客戶。

存在的問題

    前臺的代碼會常常改動，若是前臺改了代碼後臺就要同步改動。至關於一個功能的修改須要在先後臺同步修改2次，很是的低效，並且copy代碼讓人抓狂。若是一個功能先後臺長期不一樣步（各類緣由）那麼若是要同步一次那將是毀天滅地的體驗。

解決方案

1. 將前臺的項目改成Maven管理，利用Maven的多模塊化將DAO抽離一個單獨項目，新建的download項目引入DAO的依賴，這樣能夠一勞永逸。前臺修改之後新的項目只須要compile就能夠，很方便。
2. 將前臺項目copy一份，將用戶的參數保存而後傳入自建的request，直接調用controller層。最後得到controller返回的response。這不是HTTP請求，只是一個簡單的方法調用。可是controller層並不知道這不是HTTP請求。之後每一個周只要merge和前臺不一樣的代碼便可。

抉擇

    最終肯定方案2，前臺是一個7年老項目，沒有用Maven，改爲Maven而後抽離DAO風險和工做量太大。

第二個方案前期工做量大，可是也是一勞永逸。

踩坑

    Web項目改爲Java項目須要修改不少配置

1. Hibernate配置的數據庫鏈接池要繼續保留，可是connection的數量要縮小。由於不是web項目不須要這麼多connection。
2. 其餘的JDBC的Driver最好用dbcp或者mybits等等
3. 採用註解導入DAO的時候必定要注意不要出現啓動死循環。若是在掃描一個package的同時這個package中出現SpringBeanFactory的getBean的話，就會出現掃描--》loadXML--》掃描 的死循環
4. Couldn't get connection because we are at maximum connection count (30/30),這個錯誤是由於Hibernate的管理連接池的釋放標準問題.以前WEB項目是自動釋放連接.轉換爲JAVA項目由於連接數量需求很大,因此要把Hibernate配置的中的連接管理改成事務結束當即釋放.<prop key="hibernate.connection.release_mode">after_transaction</prop>