用过滤器怎么关闭数据库连接
当一个action结束后再进入filter进行关闭操作
而不是进入action前进行filter?

解决方案 »

  1.   

    filter+threadLocal的方式:进入action前从连接池获取数据库连接,然后存入threadLocal;
    action执行时,从threadLocal中获取数据库连接;
    action结束后回到filter,这时再从threadLocal中取出那个数据库连接,释放掉。
      

  2.   

    action结束后会自动进入配置过的filter是吧?
      

  3.   

    应该可以在action结束后加一个拦截去过滤。
      

  4.   

    网上摘了一段
    使用ThreadLocal+Filter处理连接池的缺点
    2005年8月12日(星期五) 11点31分 作者: 刘冬 天气:  心情: 一般 
    现在网上有很多推荐利用ServletFilter和ThreadLocal来处理数据库连接池或者是Hibernate的Session工厂,原理就是结合ThreadLocal使整个请求过程用的是同一个连接实例或者Session实例!好处是1. 不用多次从连接池取连接,性能较佳(这点我持怀疑态度,因为从连接池中取连接的消耗可以忽略不计)
    2. 可以利用Hibernate的lazy load的特性
    3. 代码更加简介、好看
    4. 资源可以被可靠的释放但是我要给用这种方法的人提个醒,先列两个缺点:1. 因为过滤器必须配置url-pattern,处理你对你的系统中每一个需要用到数据库连接的页面进行单独配置(会导致web.xml文件超大),否则一些静态内容的页面也会致使占用数据库连接资源。当然这点也是有办法解决的,就是按需分配资源,当有调用getConnection或者getSession的时候再去分配资源。2. 当某些页面需要运行时间较长的操作,例如网络操作、大文件的处理等一些耗时的操作时,相比之下数据库操作仅仅是占了其中极其微小的一部分,这个时候导致的问题是,数据库连接资源被长时间占用,但是并没有进行操作。如果该页面有着非常大的并发访问时就会使连接池的连接被用完。虽然有这样的缺点,但是还是可以通过一些变通的方法来解决!在这里我只是想提醒各位开发人员在设计的时候不要光是考虑模式,模式固然重要,但也不是放之四海而皆准的东西,一个系统好不好是用户说了算,不是设计人员或者是开发人员,所以在考虑一个设计方法的时候应该比较一下优缺点以及它们给用户带来的直接后果,并做出权衡!标签: Filter ThreadLocal 数据源 Hibernate  
      

  5.   

    我不知道怎么在action后回到filter?
    我一个servlet和filter各只执行一次而已
      

  6.   

    在Filter中关闭数据库连接的思路是在doFilter中的chain.doFilter(req,res)的前面开始事务,后面提交事务。最好用try..catch...finally包起来,finally中关闭连接。这种方案对性能上开销较大,且占用数据库连接时间较长。如果web.xml不做严格的配置,请求一个图片之类的静态文件也开启事件真是可笑之极。最好用拦截器(例如Spring AOP)来做吧。