session未关闭问题

java 中 用的hibernate 。在try外面 调用openSession方法打开session，在finally中关闭session。不知这样是否有session未关闭的风险？有风险能稍微说明下嘛？

解决方案 »

  1.   

    别用openSession
    用getCurrentSession
      

  2.   

    好吧，兄弟，用openSession是有风险的
    因为这个方法每次都要打开一个session
    而且要手动关闭
    如果你忘记关闭了
    就可能导致异常或者连接池溢出，最后崩溃
    所以才建议用getCurrentSession
    它每次使用完都会自动关闭
      

  3.   


    你说的我知道，现在是我说的这样情况有没有风险。数据库的处理都在try中完成。
      

  4.   

    openSession 会不会已经打开session，即创建过session，然后某个过程抛出异常？
      

  5.   

    当在finally关闭session的时候出现了异常，那么种种异常可以被忽略，并且该对象的终结过程也会终止，未被捕获的异常会是对象处于破坏的状态，如果另一个线程企图使用这种被破坏的对象，则可能发生任何不确定的行为。正常情况下，未被捕获的异常将会使线程终止，并打印出栈轨迹，但是，如果异常发生在终结方法中，则不会如此，甚至连警告都不会打印出来。，但是如果在finally方法中通过显示的终止方法就可以避免这个问题，session.close()我不太清楚是否是显式的终止方法，如果是，那么就不存在风险
      

  6.   

    另外补上，你可以参考effective java 2的第七条：避免使用终结方法
      

  7.   

    如果你每次都自觉手动关闭SESSION的话
    应该是没有风险的
      

  8.   

    不关闭肯定是有内存溢出风险的，但是看你的业务大不大，如果不大的话就应该没事。另外最好用getCurrentSession()啊，楼主……
      

  9.   

    要使用hibernate 最好配合上spring 让它来管理这一切。
      

  10.   

    其实没什么风险，用当前的和重新打开session都是会被关闭的。只是重新打开session浪费点资源。getCurrentSession()会自己动被关闭的，而openSession()也会在try里面关关闭啊。
      

  11.   

    ok 既然你这样问的话，那就是没风险，finally就算是有异常抛出之后也会执行! 
    如果每次都是用显示session 是不是太过浪费，如果session的生命周期只在当前有效的话，希望多听听之前各位的建议！
      

  12.   

    不关闭session的后果是，随着系统的运行，数据库连接数将逐渐增多，最终导致数据库拒绝连接。
    数据库拒绝连接后，重新启动应用，原有连接将释放，此时应用又可正常运行。
    如果发现应用存在连接未释放问题而一时半会又不能正确定位时，可通过定时触发的计划任务，重新启动应用，保证应用在一定程度上可用。
    如果数据库是db2，那么可能还需要重新启动数据库所在的服务器（操作系统）。
      

  13.   


    牛啊，比较赞同这里。有没有风险，我只说我的理解，至于有没有你自己签定。假设说你要在finally中关闭，如果此时关闭抛异常呢？那么你就有必要再次在finally中显式的try吗？如果你没有捕获的话，程序应该是会出问题的。
      

  14.   

    我一般把session交给spring来维护,spring利用线程管理事务,通过事务配置确保每次连接都能得到合理释放,解放精力,为什么不用它呢?
      

  15.   

    还可以吧，不会浪费太多资源，就是需要每次都手动关闭session。