JDBC Resultset vs Rowset可以选择哪一个？

Question

所以我知道一些相对的差异,即ResultSet与数据库有"开放连接",而RowSet以"断开连接"的方式工作.

但这几乎是我理解的(可能是不正确的:)

那么我的问题是 - 在什么情况下比另一种更可取？他们各自的优势/劣势是什么？

从我的感觉是RowSet,在断开模式下工作,特别是对于"只读"查询,在高度并发的系统中会有更好的性能.那是对的吗？如果是这样的话,可以说RowSet总是比ResultSet更适合只读查询吗？
如果我正确迭代RowSet不会抛出SQL异常,但这是一个好处吗？另一个是RowSet是可序列化的.但我担心的主要是从绩效角度来看会有什么选择呢？
但它对读写查询是否重要？您可以将ResultSet同步回数据库吗？(我不确定这是否可能(它可能是,我只是不能回忆起来或谷歌它足够好:)已经有一段时间与原始JDBC ...

有任何想法吗？我的知识中有一些缺失,显而易见:)

我问的原因是我想在实现Spring-Jdbc的ResultSetExtractor接口与在处理一些数据时返回SqlRowSet之间做出选择.这个问题让我很好奇如何决定什么时候选择,除了扔硬币:)

Answer 1

我不同意JR的回答.RowSet通常是一个不错的选择,但一如既往,最佳答案取决于您的情况和您的需求.对所有内容使用RowSet不会产生功能失常的代码,但它可以提供比ResultSet更慢的性能(常见的JdbcRowSet实现是ResultSet的包装器).

如果需要在需要JavaBean的模块化代码中使用结果对象,则RowSet满足Java Bean的最低要求.

如果您正在为多线程/服务器应用程序开发代码,那么您必须接受所有Java Bean都是可变的特许权,因此不是线程安全的.因此,Resultset和RowSet都不是线程安全的.

如果您正在编写使用数据库查询的代码并将它们转换为Java数据模型对象以供在应用程序的其余部分中使用,那么RowSet的性能可能比ResultSet低.

在我编写的大量代码中,当我收到JDBC数据库查询时,我一直只是使用Resultset将检索行立即处理到数据模型对象列表中.Resultset甚至不能执行执行转换的方法调用.在我看来,这很好......因为Resultsets(以及RowSets)消耗了大量资源,并且您希望它们尽快可用于gc.

在这种模式下,我甚至不需要Resultset的任何新功能,更不用说RowSet了.我只需在集合中向前迭代一次并生成结果行列表.

在某些情况下,RowSets是非常需要的.由于RowSets是可序列化的并且表面上是"轻量级",因此断开连接的CachedRowSet(例如)表示在位置之间传输数据库查询结果的合理有效机制,特别是如果您希望数据可以在原位更新.当然,您也可以序列化并传输对象列表.

Answer 2

RowSet几乎总是正确的选择,它更全功能,并具有您列出的所有好处,以及具有特殊用途的专门实现,如断开连接CachedRowSet,这是我在数据适合内存时总是使用的,所以我可以发布尽可能快地重新连接回池.

连接ResultSet/Rowset应该永远不会逃避方法,或者最坏的情况是创建它们的对象.至少有一个RowSet你可以断开它,客户端不必关心实现.*除非您正在编写JDBC与ResultSet特定功能或合同相互作用或依赖的特定库代码.

如果您只是转移查询结果,则JDBC特定类应该是您的公共合同的一部分.

在大多数情况下,您希望实现一个List/Set域对象来操作和使用,而不是将代码直接耦合到JDBCapi.

现有许多现代版本ResultSetMapper<T>用于处理使用Visitor模式生成类型安全域实例,因为这是惯用的方式.