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

iceant 02-10-16

能保证所有的 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, 怎么办? 如果是我,我就自杀去,呵呵 开玩笑。这种痛苦是不言而喻的。



2Go 1 2 下一页