关于download项目的一点总结

背景

网站有很多table提供download all的功能，简单来说就是能将table的全部数据以CSV的文件形式发送到客户的注册邮箱。动辄几千万的数据量注定这个功能不适合在前台Tomcat中完成，所以才有一个单独的项目负责处理客户的请求，以队列形式完成客户请求。

这个功能之前和后台的项目是整合在一起的， 主要做法是把前台的DAO等逻辑复制到后台，通过读取客户提交的参数模拟和前台一样的查询，最后的出结果发送给客户。

存在的问题

前台的代码会经常改动，如果前台改了代码后台就要同步改动。相当于一个功能的修改需要在前后台同步修改2次，非常的低效，而且copy代码让人抓狂。如果一个功能前后台长期不同步（各种原因）那么如果要同步一次那将是毁天灭地的体验。

解决方案

将前台的项目改为Maven管理，利用Maven的多模块化将DAO抽离一个单独项目，新建的download项目引入DAO的依赖，这样可以一劳永逸。前台修改以后新的项目只需要compile就可以，很方便。

将前台项目copy一份，将用户的参数保存然后传入自建的request，直接调用controller层。最后获得controller返回的response。这不是HTTP请求，只是一个简单的方法调用。但是controller层并不知道这不是HTTP请求。以后每个周只要merge和前台不同的代码即可。

抉择

最终确定方案2，前台是一个7年老项目，没有用Maven，改成Maven然后抽离DAO风险和工作量太大。

第二个方案前期工作量大，但是也是一劳永逸。

踩坑

Web项目改成Java项目需要修改很多配置

Hibernate配置的数据库连接池要继续保留，但是connection的数量要缩小。因为不是web项目不需要这么多connection。

其他的JDBC的Driver最好用dbcp或者mybits等等

采用注解导入DAO的时候一定要注意不要出现启动死循环。如果在扫描一个package的同时这个package中出现SpringBeanFactory的getBean的话，就会出现扫描--》loadXML--》扫描 的死循环

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>