以文本方式查看主题 - 中文XML论坛 - 专业的XML技术讨论区 (http://bbs.xml.org.cn/index.asp) -- 『 Java/Eclipse 』 (http://bbs.xml.org.cn/list.asp?boardid=41) ---- jdbc资源的回收问题[转载] (http://bbs.xml.org.cn/dispbbs.asp?boardid=41&rootid=&id=10232) |
-- 作者:admin -- 发布时间:9/23/2004 12:39:00 AM -- jdbc资源的回收问题[转载] ● jdbc资源的回收问题[转载]发信人: petbear (雨中的人), 信区: J2EE 标 题: jdbc资源的回收问题[转载] 发信站: BBS 水木清华站 (Sun May 9 11:33:20 2004), 站内 我们使用连接池访问数据库,是不是在关闭了connection之后它所属的statement和resul t都会自动关闭了呢?就是说只需要关闭connection? 那么这样的话是不是只要在try{...}catch{...}finnally{conn.close();}这样的框架下工 作就肯定是不会存在连接资源占用的情况了呢? 经过我在DB2上测试的情况是这样的,不知道是不是不同的jdk或者as环境下会有所不同? 我一直无法完全肯定这一问题,请大家赐教! 本来我只要养成在关闭connection之前把其他对象一一关闭的习惯,就不会存在这个问题 了,但是我为了偷懒起见,把简单的查询和更新操作封装到了一个基类的公用函数中,方 便随时在代码中调用,代码如下: public static ResultSet sysSelect(Connection conn,String sql)throws SQLExcepti on{ Statement st = null; st = conn.createStatement(); return st.executeQuery(sql); } 由于这样的功能随时随地会被使用,这不得不使我考虑这个函数中产生中间对象statemen t st的生存期问题!*_* Re: jdbc资源的回收问题! 发表时间: 2004年04月15日 10:47:19 回复 发表人: FgtPWD 发表文章: 6 / 注册时间: 2004-04 帮你顶,我也想知道清楚 Re: jdbc资源的回收问题! 发表时间: 2004年04月15日 14:56:56 回复 发表人: oldma 发表文章: 86 / 注册时间: 2003-09 是,最起码数据库端资源是得到了释放 不过这也不绝对,因为statement,result对应的是curior,而有些 DB的curior是share的, 总之,关了connection就可以了 Re: jdbc资源的回收问题! 发表时间: 2004年04月16日 17:05:07 回复 发表人: mysapphire 发表文章: 17 / 注册时间: 2003-12 你是说:在有的时候就算是释放了connection也可能有部分的Statement和ResultSet还占 用着数据库资源? 如果是这样的话,那么在这个时候java和数据库的连接虽然断开了,可由于没有在连接的 时候预先释放这些Statement和ResultSret资源(在数据库方应该理解为游标或者其他资源 ),会影响数据库的性能的吧?这似乎无以从程序上来证实! Re: jdbc资源的回收问题! 发表时间: 2004年04月18日 20:41:05 回复 发表人: oldma 发表文章: 86 / 注册时间: 2003-09 > 你是说:在有的时候就算是释放了connection也可能有部分的 > tatement和ResultSet还占用着数据库资源? 不会,本地的statement和ResultSet会被回收,但数据库端的资源不一定会释放,但你不 必担心此事,应为这不是一件坏事,就像你用的数据库连接池,数据库也可以对curior做 cache,毕竟频繁创建curior对DB来说是比较expansive的. 当然,前提是数据库share_curior参数的设置不是0 Re: jdbc资源的回收问题! 发表时间: 2004年04月16日 17:16:17 回复 发表人: seaman0916 发表文章: 19 / 注册时间: 2004-02 关注,我对这个问题也一直搞不清楚! Re: jdbc资源的回收问题! 发表时间: 2004年04月19日 12:51:46 回复 发表人: TiGEr.zZ 发表文章: 7 / 注册时间: 2004-04 本地对象如果不被使用的确可以释放,但tcp连接什么时候释放是个问题,还有tcp连接和 connection对应还是和resultset对应,这个似乎是未知的,不过看起来java里似乎是和c onnection对应的,否则只需要全局维护一个长连接connection对象就可以了,只考虑生成 (是否可用)的问题而不用考虑关闭的问题(除非出于性能目的,可以考虑多连接加锁的实 现,也无需用户去关闭),ado里面好像可以这么做。如果tcp连接过多,一定会把数据库拖 垮的。 至于conn, rs, st之间的依赖关系似乎也不明确,所以我在这个时候是自己写一个result set接口的实现,然后重载close方法,去一一关闭其依赖对象,甚至你可以在final函数里 面关闭,不过后者看起来没什么大用。 Re: jdbc资源的回收问题! 发表时间: 2004年04月19日 13:37:52 回复 发表人: navyzhu 发表文章: 7 / 注册时间: 2003-03 Statement也要Close,本人在使用中发现,若单单调用Connection.Close,实际上Connect ion并不会立即Close,可能要等到垃圾回收Statement后Connection才会Close, 本人使用的 数据库是SQLServer. Re: jdbc资源的回收问题! 发表时间: 2004年04月19日 14:48:17 回复 发表人: jellyprince 发表文章: 11 / 注册时间: 2004-04 我曾试过将Connection对象作为一个static属性放在一个类DBConnection中,然后,建立 一个连接后,其它所有要用连接的地方就调用 DBConnection.connection, 最后再关掉,本以为这是一高招,但结果却是不可行。connection被用一次后,调用DBCo nnection.connection时就不行了。 但我认为思路应该是对的,不知是否还有同志尝试过 至于statement,要关掉并不难,可以在一个要连某个数据库的类中将其可connection一同 声明为static,这样在任何地方用完后,就可以很方便的关掉了 Re: jdbc资源的回收问题! 发表时间: 2004年04月19日 14:53:33 回复 发表人: rtm 发表文章: 13 / 注册时间: 2002-11 全部都要关闭,关闭connection后statement和result还是可以用的,可以在关闭connect ion后,再试试遍历result还是可以得到数据的,result不关闭会导致游标超出范围等错误 Re: jdbc资源的回收问题! 发表时间: 2004年04月19日 15:13:02 回复 发表人: mysapphire 发表文章: 17 / 注册时间: 2003-12 请问navyzhu和rtm: 你们是在什么数据库上测试得到的这个结果的? 我在DB2和ORACLE8.1.2上测试出来的结果都很明显地提示:SQLException:关闭的连接... .(所有的conn,st,rs使用的时候是默认方式) Re: jdbc资源的回收问题! 发表时间: 2004年04月19日 15:22:43 回复 发表人: huzhigang 发表文章: 23 / 注册时间: 2003-12 Connection一旦关闭,所有由它打开的ResultSet不在可用。这在jdk文档中有说明。否则 ,没有必要定义javax.sql.RowSet了。 Re: jdbc资源的回收问题! 发表时间: 2004年04月20日 10:50:17 回复 发表人: shardy 发表文章: 4 / 注册时间: 2003-04 Statement,ResultSet肯定都是关闭了得,但是资源还没有释放阿。如果从性能方面考虑的 话,一定的明显的关闭Statement,ResultSet,还有两点需要注意: 1,不要隐式产生Statement,ResultSet对象 2,关闭对象一定要在finally中关闭 Re: jdbc资源的回收问题! 发表时间: 2004年04月19日 15:21:25 回复 发表人: TiGEr.zZ 发表文章: 7 / 注册时间: 2004-04 这么看来odbc/jdbc的设计现在也不太适宜了,为什么有conn, st的存在是因为希望可以复 用,减少开销,但增加了程序员的负担,可能不多的几行代码,建立对象和关闭对象占了 一半。甚至复用也很难实现,因为很多页面中可能只访问一两次数据库,如果没有自己设 计或者底层的连接池,页面切换该消耗的还是要消耗。就算不是这样,按照设计的一般标 准,需要把粒度细化,这样结果和上面一样,如果要重用,必须附加上多余的耦合变量, 更加不好。 反过来有了连接池,也基本上不需要conn,或者st,后者根据使用者的经验,似乎可以表 达为得到rs后就可以关闭或者直接重用。conn也是可以重用的(否则也就不能连接池了) ,不过大概需要在前一个返回的resultset被关闭之后,也就是我说的和tcp连接对应的概 念,这个和ado不同。 Re: jdbc资源的回收问题(To mysapphire)! 发表时间: 2004年04月19日 17:48:06 回复 发表人: navyzhu 发表文章: 7 / 注册时间: 2003-03 我用的数据库是SQLServer2000,程序是一个数据月结程序,开始我发现月结有时成功,有 时失败,看了后台才发现因为Statement没有Close,所以Connection太多以至于打开几百个 Connection,结果处理失败。 Re: jdbc资源的回收问题! 发表时间: 2004年04月20日 11:01:32 回复 发表人: xunzy 发表文章: 4 / 注册时间: 2004-04 JDBC3.0规范中提出了一个新的规范:把Statement也进行缓存(一般是应用服务器厂商实 现),这样就可以在不同的connection之间可以共享Statement。所以我个人以为,在释放 connection之前,最好先close Statement,这样有利于statement的重用(而且这也是规 范所推荐的比较好的编程习惯)。 Re: jdbc资源的回收问题! 发表时间: 2004年04月20日 11:35:01 回复 发表人: cats_tiger 发表文章: 79 / 注册时间: 2003-05 Statement和PreparedStatement已经将数据库操作封装的很好了,所以我从来不再作一个 类完成类似的操作。另外connection资源一定要用完就关。不要返回ResultSet对象,用R owSet代替。 Re: jdbc资源的回收问题! 发表时间: 2004年04月20日 16:34:19 回复 发表人: arthurlian 发表文章: 5 / 注册时间: 2003-09 我在oracle中,如果不关statement,最后oracle会报错 ORA-1000: max cursor exceeded. 可以在 v$open_cursor中查询未关闭的cursor. 最好还是用完就关。 Re: jdbc资源的回收问题! 发表时间: 2004年04月20日 21:25:38 回复 发表人: mysapphire 发表文章: 17 / 注册时间: 2003-12 有一点应该是统一的吧?那就是:当直接connection.close()的时候java端的st对象资源 必定已经被释放了,而在DB端相应的cursor资源也许不会马上释放,不同的DB厂商针对这 有情况有不同的资源回收策略。 但问题是:是不是正如oldma所说的那样,我们也可以把DB端的资源回收当作黑盒(或者一 个能自我调整的容器)来看待,而不必去关心它的溢出或者阻塞???正如我们现在经常 使用的连接池pool一样!! 1)如果是这样的,那么我们可以只处理connection的关闭,因为connection的关闭会自动 引起java端的rs、st和pst的关闭,而在DB端,则有cache可以复用这些未被显式释放的cu rsor资源,使这些资源不至于被挂起; 2)如果不是这样,那么我们必须手工关闭rs、st和pst这些与数据库资源对应的对象来释 放DB端的资源,然后在最后关闭conn,因为DB不会聪明地调度这些被挂起的资源,不主动关 闭它们会导致DB资源被耗尽。 通过回答这一问题,请大家告诉我,我在发帖的时候写的那个函数在极度频繁被调用时可 行吗?因为这个函数不处理任何close()操作,只是根据调用者的connection参数和Strin g参数返回rs给调用者,在调用者的代码的最后会有rs.close()和connection.close()操作 ,但是肯定不会有st.close()。 那么这个未被显式地close()的st就是我一直不清楚的东 西,在非常频繁地被重复这样调用(事实上这样的调用就象out.print()一样多)后,D B端会是怎样一种情况? Re: jdbc资源的回收问题!(To mysapphire) 发表时间: 2004年04月21日 09:00:06 回复 发表人: navyzhu 发表文章: 7 / 注册时间: 2003-03 对于频繁调用的函数Connecton及Statement绝对要Close,正如其他网友所说,不同的数据 库可能有不同的实现,但考虑到重用及数据库的移植等问题,还是Close吧。 Re: jdbc资源的回收问题!(To mysapphire) 发表时间: 2004年04月21日 09:24:03 回复 发表人: flag 发表文章: 3 / 注册时间: 2004-04 有道理! ※ 来源:·BBS 水木清华站 smth.org·[FROM: 211.71.11.*] 索引页面|上一篇|下一篇
|
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
4,203.125ms |