相关内容

我刚刚完成了一个大型零售商的咨询工作，我们通过一些相对简单的变化，成功将Hibernate应用程序的性能提高了大约两个数量级。这真的让我深刻地意识到，我见过的几乎所有性能问题都可以通过以下方式之一或两者来解决：

我们使用关系型数据库技术的其中一个原因就是现有的RDBMS实现提供了非常成熟、可扩展和强大的并发控制。这意味着远不止简单的读写锁。例如，使用锁的数据库在特定事务获得/许多/锁时被设计成高效扩展 - 这被称为/锁升级/。另一方面，一些数据库（例如Oracle和PostgreSQL）根本不使用锁 - 相反，它们使用多版本并发模型。这种复杂的并发处理方法旨在实现比传统锁定模型更高的可扩展性。数据库甚至允许您指定所需的交易隔离级别，这样您就可以在隔离性和可扩展性之间进行权衡。

Jason在指出了一些关于Hibernate当前版本的有意思的事情。

针对我关于准则查询的帖子有很多评论。我终于找到时间来回应。很多人建议一个更树状的方法，我们将所有逻辑运算符视为二元运算符。例如，匿名者建议以下内容

大约两年前，一个同事天真地问我：“标量类型究竟是什么？”

Chris Winters不喜欢面向对象的查询API。由于Hibernate强调查询/语言/方法，所以我不太可能是反对他的人。准则查询无疑更嘈杂。而且，我见过的查询语言往往更易于表达。在查询语言中编写算术甚至逻辑表达式都非常容易，但在面向对象的准则API中则不然。

在计算中，名称非常重要。真的非常重要。我说的不是用像UpdateUserDetailsCommand这样的有意义的名称来代替UpdUDetsCd。我是指产品本身的名称。一个出色的名称能告诉我们很多关于一款软件的信息：它告诉我们创造者有一些想象力，甚至有些时尚感。它告诉我们这个人非常重视产品的成功，他们理解，制作优秀的软件不仅仅在于编写优秀的代码。

Hibernate 2.1的一个重大改进是我们终于拥有了一个成熟的Criteria查询API。我很长时间都没有推进这个特性，因为我一直不确定它应该是什么样子。我查看过的每一个QBC API都是设计不同的，肯定没有什么标准API可以借鉴。我见过从这种

我们正在仔细研究SDO。这是一个有点出人意料的有趣规范。我的理解是，它提供了一种操作对象图或看起来足够像对象、可以有意义地表示为图的实体或事物的机制。例如，XML。