所以我知道一些相对的差异，即ResultSet与数据库有“开放连接”，而RowSet以“断开连接”的方式工作。
但这几乎是我的理解（可能不正确:)
我的问题是 - 在什么情况下比另一种更可取？他们各自的优势/劣势是什么？
从我的感觉RowSet，工作 断开模式尤其适合 “只读”查询会有 高效的表现 并发系统。那是对的吗？ 如果是这样的话，可以说是安全的 RowSet总是比较好 用于只读查询的ResultSet？
如果我正确地迭代了 RowSet不会抛出SQL异常， 但这是一种好处吗？另一个 因为RowSet是可序列化的。 但我担心的主要是来自a 性能视角会是什么 选择？
有什么想法吗？我的知识中存在一些缺失，显而易见：）
我问的原因是我想在实现Spring-Jdbc的ResultSetExtractor接口与在处理某些数据时返回SqlRowSet之间做出选择。这个问题让我很好奇如何决定在什么时候选择，除了掷硬币之外：）
答案 0 :(得分：24)
我不同意JR的回答。 RowSet通常是一个不错的选择，但一如既往，最佳答案取决于您的情况和您的需求。对所有内容使用RowSet不会产生功能失常的代码，但它可以提供比ResultSet更慢的性能（常见的JdbcRowSet实现是ResultSet的包装器）。
如果需要在需要JavaBean的模块化代码中使用结果对象，则RowSets满足Java Bean的最低要求。
如果您正在为多线程/服务器应用程序开发代码，那么您必须接受所有Java Bean都是可变的特许权，因此不是线程安全的。因此，Resultset和RowSet都不是线程安全的。
如果您正在编写使用数据库查询的代码并将它们转换为Java数据模型对象以便在应用程序的其余部分中使用，那么RowSet的性能可能不如ResultSet。
在我编写的大量代码中，当我收到JDBC数据库查询时，我一直只是使用Resultset将检索行立即处理到数据模型对象列表中。 Resultset甚至不能执行执行转换的方法调用。在我看来，这很好......因为Resultsets（以及因此RowSets）消耗了大量资源，并且您希望它们尽快可用于gc。
在这种模式下，我甚至不需要Resultset的任何新功能，更不用说RowSet了。我只需在集合中向前迭代一次并生成结果行列表。
在某些情况下，RowSets是非常需要的。由于RowSets是可序列化的并且表面上是“轻量级”，因此断开连接的CachedRowSet（例如）表示在位置之间传输数据库查询结果的合理有效机制，特别是如果您希望数据可以在原位更新。当然，您也可以序列化并传输对象列表。
答案 1 :(得分：9)
RowSet几乎总是正确的选择，它更全面，并且具有您列出的所有好处以及针对特殊用途的专门实现，例如断开连接CachedRowSet这就是我总是当数据适合内存时使用，所以我可以尽快将连接释放回池中，以便重用。
ResultSet永远不应成为公共合同的一部分。连接的ResultSet/Rowset永远不应该逃避该方法，或者最糟糕的是创建它们的对象。至少使用RowSet，您可以断开它，客户端不必关心实现。 *除非您正在编写JDBC特定的库代码，以交互或依赖ResultSet特定功能或合同。
如果您只是转移查询结果，JDBC特定类应该是您的公共合同的一部分。
RowSet/ResultSet内容具体化为要传递的类型安全域对象。在大多数情况下，您希望实现List/Set个域对象的操作和使用，而不是将代码直接耦合到JDBC api。
存在ResultSetMapper<T>类的许多现代版本来处理使用Visitor模式生成类型安全域实例，因为这是惯用的方式。