异步检索SQL查询执行结果。

Question

经过相当多的研究之后，我决定继续写下一个在堆栈溢出中可能看起来相当多余的问题，但我只是问，因为我没有找到我的答案。我一直对Java NIO2框架有一些乐趣，它极大地提高了我的应用程序的可伸缩性。 （我们之前使用旧式I/O TPC服务器/客户端设置来安装一些适度的模拟服务器），并让我告诉你。如果你知道我的意思，那么并发是B皇后。

我们正在从使用线程作为所有事情的答案（试图更好地实践并更熟悉推进技术）。以前，我们为用户数据使用平面文件存储（文本/二进制格式存储），并将所有内容都迁移到SQL数据库。

虽然这样做我已经注意到通常没有问题，但是在数据库上等待永远不会有趣，并且在模拟的游戏环境中等待数据库调用从来没有乐趣，尤其是当整个游戏服务器在等待。这是我们通常会替换线程的地方。为什么不只是使用Thread pool或类似的命令在另一个线程上执行SQL调用。

对于任何类型的异步事件，Java NIO2 CompletableFuture<K,V>确实是一个很大的帮助，但是我一直在试图找到一种将这种方法用于SQL调用的方法。我认为编写我们自己的使用NIO2的JDBC版本始终是一种选择，但它看起来有点过度消耗，可能需要更多的时间和金钱。请记住，我们只是一个小型模拟社区，而不是一个大型企业，但我们确实想确保为用户提供质量。

我正在调查jooQ这似乎没问题，但它也似乎有点过分杀。这使用CompletableFuture#supplyAsych方法，但可用的例子并没有真正解释它的深入。但是它混在这句话：

总是会有一个阻隔屏障这样的解决方案，那就是 JDBC本身 - 这是很难变成一个异步API。实际上，很少数据库确实支持异步查询执行。

但是，数据库不一定需要支持异步查询执行，才能在异步上下文中提供结果。如果我的服务器没有等待（只等待）API才能获得查询结果，那么这是唯一真正重要的事情。与此相似的活动可以使用来自Unity的脚本参考的示例来解释：CoRoutines。

请不要推荐Scala。

Answer 1

Java NIO2的级别太低，无法为您提供帮助。

开发JDBC的异步版本的你“思想泡沫”是有问题的，原因有二：

• 它确实不适合与事务在JDBC API层之上实现的方式（即在应用程序代码）。同时在较少数量的线程上处理多个事务的应用程序将变得更加复杂。更复杂（通常）意味着不太可靠，这不是您在执行（常规）数据库操作时想要的。

• 设计一个异步JDBC API是一回事，但实现它是另一回事。这里真正的问题是，真正的工作是在多个 JDBC驱动程序发生：

  • 一些驱动程序是专有的。
  • 所有驱动程序都会将某种非标准“协议”与后端数据库（在JVM中或通过网络连接）进行对话。
  • 这些协议（AFAIK）在本质上总是同步的，并且通常是专有的。
  • 用支持异步模式的东西更新或替换协议需要自行更改数据库实现。

那么解决方案是什么？

那么这个问答& A有一定的联系，以试图实现异步数据库API项目：“Is asynchronous jdbc call possible?”。我想，如果你不满意（即进度或API），你可以开始你自己的项目。但是，您有可能遇到同样的设计和实施问题。

另一种方法可能是完全放弃SQL和ACID，并查看一些所谓的“NoSQL”数据库，以查看它们是否为您提供了所需的异步API和行为。