多年来，hibernate.org首次推出了一个全新的顶级子项目！
响应式编程和关系数据库
响应式编程允许我们利用非阻塞IO来降低程序中的资源使用。长期以来，非阻塞IO一直不是与关系数据库交互的程序的选择，因为数据访问API如JDBC和ODBC都是围绕一个本质上同步、阻塞的模式设计的。
这种情况最近有所改变，随着像PostgreSQL、MySQL、Db2和SQL Server的Vert.x客户端API等举措，以及其他类似的项目。因此，现在Java程序可以以完全异步、非阻塞的方式与关系数据库交互。
此外，如Mutiny（Mutiny）之类的API使用流而不是嵌套回调简化响应式编程，至少缓解了Java中异步编程的一些痛苦。
但当然，在2006年，当我们设计Java持久化API来简化Java中的ORM并统一当时存在的ORM实现时，“响应式编程”根本没有人注意到。因此，JPA本质上是阻塞的。所谓的“响应式ORM”根本不存在。
ORM的响应式API
因此，今天我们向社区介绍Hibernate Reactive，这是一个针对Hibernate ORM的响应式API，它支持非阻塞数据库客户端和作为与关系数据库交互模式的响应式编程。
Hibernate Reactive重用了Hibernate ORM的大部分实现，但用围绕响应式流的新层替换了与JDBC交互的代码，并向程序员暴露了一个新的响应式Session API。
实际上，有两个响应式Session API，一个用于使用Mutiny的程序，另一个用于使用Java的CompletionStage的程序。
// Mutiny-based API
factory.withTransaction(
// retrieve a Book
(session, tx) -> session.find(Book.class, bookId)
// delete the Book
.chain(book -> session.remove(book))
)如果您之前使用过Hibernate，并且也使用过响应式流进行过一些编程，那么您应该会立刻感到熟悉Hibernate Reactive。如果您从未使用过Hibernate，或者从未进行过响应式编程，那么这是一个学习新东西的机会，我们将在这里提供帮助！
无论哪种情况适用于您，最佳起点是我们的Hibernate Reactive简介。
整体情况
Hibernate Reactive仅在端到端响应式技术堆栈的背景下才有真正的用处。因此，我们当然要确保它与Vert.x配合得很好，并且可以轻松集成到其他平台。
但令人兴奋的消息是，我们还将它集成到一个即将宣布的新响应式API Quarkus 中。我们的目标是提供最舒适、最熟悉的Java开发者过渡到响应式编程模型的方式。
在未来的文章中，我们将详细介绍Quarkus中的响应式数据访问。
我们还在努力扩大支持的数据库列表。目前，仅支持PostgreSQL、MySQL和Db2，但我们希望很快就能引入对SQL Server的支持。
性能考虑
虽然这个项目的直接目标是让您能够在非阻塞数据库客户端库中以及响应式编程模型中使用ORM，但很明显，我们希望与使用ORM和阻塞JDBC驱动程序相比，能够获得一些性能上的好处。另一方面，不能合理地期望Hibernate Reactive在所有情况下，甚至大多数情况下都比常规Hibernate ORM快。
特别是，如果您在笔记本电脑上测试数据访问性能，使用一个访问本地数据库的程序，数据库中的数据量很小，完全适合数据库的缓存，那么您完全没有理由期望使用Hibernate Reactive会看到性能提升。我们并没有神奇地让它从内存中读取字节更快！
但即使在许多更现实的情况下，响应式代码也不一定比使用阻塞I/O的常规代码更快。为了测量效果，您需要一个许多服务器线程会阻塞等待远程数据库服务器响应的情况。
在我们的测试中，我们确实看到了证据表明，使用Hibernate Reactive的代码在模拟这种情况的测试环境中，其性能下降比使用常规Hibernate ORM的代码更加平缓，但我必须强调，这些是初步结果，不一定适用于所有系统。
因此，像往常一样，我强烈建议您在自己的生产运行环境中，使用自己的典型工作负载进行自己程序的性能测试。
另一方面，我们甚至还没有开始优化Hibernate Reactive的性能，所以最初的性能测试结果实际上是非常令人鼓舞的。
