1

在具有嵌入式 Derby 数据库的桌面应用程序中，我应该在应用程序的整个生命周期中保持什么（而不是每次与数据库对话时都重新创建）？

  1. Connection并且Statement，在程序的整个生命周期中使用相同的语句？
  2. Connection，重复创建语句？
  3. 这些都不是。也就是说，重复地重新创建连接和语句？

从数据库爱好者的角度来看，避免重新创建不需要重新创建的任何内容似乎是合理的，但是选项 1（或 2）是否违反标准做法，还是有一些明显的缺点？（重新）创建连接和语句是否昂贵？

4

2 回答 2

1

连接确实很昂贵（可能需要几百毫秒）。然而，连接的生命周期是有限的，语句和结果集取决于它的生命周期。每当释放超过 30 分钟时，平均数据库将超时并断开连接。您可以在代码中添加一些超时检查器，以便它“自动”重新获取连接，但这是一项繁琐的工作，如果您不知道它应该如何工作，那么很容易出现错误。而是使用现有的、彻底开发且健壮的连接池，如C3P0 ，并以通常的方式编写 JDBC 代码（在尽可能短的范围内获取和关闭所有资源）。应该是这样的。

尽管在理论上（并且显然在实践中）嵌入式数据库连接会更便宜并且连接可以永远存在，但我强烈反对在 JDBC 代码中以不同的方式处理嵌入式数据库。它会使您的 JDBC 代码在语义上存在缺陷并且完全不可移植。每当您想分发它和/或更改为具有更多功能的真实 RDBMS 服务器时，您都必须重写/重新实现所有内容。

于 2010-03-10T12:20:16.367 回答
1

在嵌入式Derby 应用程序中，Connection 和 Statement 对象都非常便宜，我认为您不必担心在需要时创建它们。在 Derby 单元测试套件中，我们可以毫无问题地创建数万个连接和数十万个语句。

只要你愿意，你也可以保留你的 Connection 和 Statement 对象。Embedded Derby 没有时间限制，并且不会丢弃连接或语句对象，除非您告诉它（通过关闭它们），或者除非您将它们泄露出去，在这种情况下，垃圾收集器将清理它们（最终）。

尽管保持连接很好，但您应该在事务完成时提交（）事务（当然，除非您在自动提交模式下运行）。

而且，如果您保留一个结果集，请注意提交事务通常也会关闭结果集，而不是您专门构建在提交期间保持打开的特殊结果集。

于 2010-03-10T15:27:12.127 回答