关于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>