关于:查询数据库后是返回ResultSet还是返回Collection

02-10-16 iceant

能保证所有的 ResultSet 都能 Hold 住吗?
据我所知,ResultSet依赖于具体实现.
有的 JDBC Driver 在 Connection 关闭时,会自动检测
所有打开的资源是否已关闭,如果没有,就会等待一段时间,然后
将所有的资源关闭掉.(这里的资源指 Statement,ResultSet)

所以,使用文中所说的方法并不安全.

有时在应用中要做权衡,并不是快就好.我认为,宁愿慢一点,
也不要出错. 所以,返回 List 还是比较通用的.

iceant

2002-10-16 10:34

附 Start JDBC 文中的一段话:

6.1.9 Holdability
It is sometimes the case that any ResultSet objects created during a transaction are closed when the transaction is committed. If that is not the desired behavior, a ResultSet object may be created so that it stays open after the Connection method commit has been called. (This is sometimes referred to as holding a cursor over a commit.) Such a ResultSet object will remain open until it is explicitly closed; therefore, an application should call the method ResultSet.close on it as soon as it is no longer needed.

To specify the holdability of ResultSet objects that are created, the following constants can be supplied to the Connection methods createStatement, prepareStatement, and prepareCall:

ResultSet.HOLD_CURSORS_OVER_COMMIT
ResultSet objects (cursors) are not closed; they are held open when the method commit is called.
ResultSet.CLOSE_CURSORS_AT_COMMIT
ResultSet objects (cursors) are closed when the method commit is called. Closing cursors at commit can result in better performance for some applications.
The default holdability of a ResultSet object depends on how the DBMS and driver are implemented. You can call the DatabaseMetaData method getResultSetHoldability to get the default holdability for result sets returned by your DBMS and driver.

banq

2002-10-16 11:01

JDK1.4中写明close Statement会清除ResultSet
但是close PrepareStatement没有说一定会清除ResultSet，

实际使用中，我们已经大量使用PrepareStatement，close它后，再操作ResultSet。

我想JDBC的标准是根据实践制定的，如果这个算它的一个BUG,恐怕会将BUG转为标准。

为什么这样的重要问题 sun或java社区不去解决，因为使用J2EE就没有这些问题，现在的精力
都放在EJB的标准制定上。

所以对于我们根本解决之道是迅速转上J2EE开发框架，脱离全部依靠Jsp/Servlet打天下的落后方式。

iceant

2002-10-16 13:39

PreparedStatement extends Statement

接口上他们是继承的关系,具体实现就要看具体实现者是怎么做的啦.

"为什么这样的重要问题 sun或java社区不去解决，因为使用J2EE就没有这些问题"

这和用不用 J2EE 是两回事,我认为在 JCP 里没有人去讨论这个问题,
是因为没有人想过这样用.所有的教材都告诉人们,要及时关闭对数据对象.
没有人想承担 JDBC 不兼容的风险.既然 JDBC 指导里都这样写,所以大家都这样做.

我并不否定这种做法,这个想法是很好,很有新意,减少了内存拷贝的操作.节约了时间.
但是它并不通用. 遇到不同的 JDBC 要小心处理.这对于程序员来说,增加了程序移植的工作量.可维护性差了一点.

"所以对于我们根本解决之道是迅速转上J2EE开发框架，脱离全部依靠Jsp/Servlet打天下的落后方式。 "

只要自己做好就行了,别人有别人选择的权利,没必要强求.
对于有的应用, 一个 JSP/Servlet 就搞定的,确实没必要用 Framework.

banq

2002-10-16 14:09

最后的观点还不是很同意。

目前JSP/Servlet 能搞定的一些项目应用其实PHP也都搞定过，只不过JSP/Servlet在速度和性能上在理论上高于PHP,但是由于java本身的性能问题，因此这个速度差异我个人认为不是很大，这也是为什么PHP能继续发展和生存的原因。

Java给我们带来的不是一个PHP的语言替代物。
Java带来的革命性时代都在J2EE中。

为什么要竭力宣传大家使用J2EE？因为这是个台阶问题，是个阶段问题。
比如一个公司做游戏，招了一大批刚毕业的大学生，使用jsp/servlet/java class构建了一个中型系统，虽然系统能够运行，但可想而知系统的拓展性和可维护性以及性能了。

现在公司开发项目，一般都是中型项目，而且会跟踪开发，怎么能不用J2EE?

当然一两个人做个项目是没有必要使用J2EE,但是项目的发展性和扩展性？

举个例子说：集群技术，如果你的应用超过一台服务器以上，你怎么办？你能让你的访问量超过一台服务器的负担，说明你走的道路并不短，项目代码也不会很短，如果你没有使用J2EE, 怎么办？如果是我，我就自杀去，呵呵开玩笑。这种痛苦是不言而喻的。

iceant

2002-10-16 17:45

^_^ 你都知道你的前提是在做项目.
如果说是日常维护,比如现在一些比较正规的公司都有 IT 部门,
他们做什么?就做公司内部网络和应用的开发与维护.
如果说有一天,财政部说,我想要个能群发的基于 WEB 的应用,
那你还去用 Framework 吗?直接一个 Servlet/JSP + JavaBean 就搞定了.
而且,这个东东能用超过两个月就不错了.

这只是一个极端的例子!! 我很同意你说的,那是一个阶段问题.
我把它叫做水平问题. 我也认为,一开始的时候就应该学用或选用
好的框架,好的结构,好的设计.

但是世事都要看需求,看具体情况,一味地想着用高深的东东,未必就是好事

2002-10-16 19:05

这问题真的这么重要吗?
建议超过一定数量的回复问题停止讨论,本来我有自己的观点,不敢说了.
大家说的都对.结束.散会.

深蓝大盗

2002-10-22 14:26

感觉这种方法有问题：
１、数据库连接不能断开，否则不能使用Iterator.next()；
２、每次占用的内存虽然少，但是至少也得花费一条记录所需要耗费的内存；
３、每操作一条记录就需要访问一次应用服务器，甚至数据库服务器（跟页命中率有关）；
４、至少是不适合用于EJB上的。

另外想请问版主是否没有动手去试试看，难道只是看到国外的一些文章，感觉精妙，然后翻译过来吗？

深蓝大盗

2002-10-22 14:32

版主说，“JDK1.4中写明close Statement会清除ResultSet
但是close PrepareStatement没有说一定会清除ResultSet，
实际使用中，我们已经大量使用PrepareStatement，close它后，再操作ResultSet。”
可是版主有曾看到PreapareStatement中并没有重新实现close方法，而是Methods inherited from interface java.sql.Statement
...close...