1

根据Datomic 的连接文档：

数据连接不遵循获取/使用/释放模式。它们是线程安全的、缓存的和长寿命的。许多进程（例如应用程序服务器）永远不会调用释放。

我很想知道这是如何在实践中实现的，特别是对于 sql 连接。从客户端/用户的角度来看，这非常好，因为您根本不需要担心线程池，它简化了客户端代码，以及您需要大量推理的内容。这是我喜欢在其他具有 SQL 连接的应用程序中复制的东西。

将问题分解成更小的部分：

  • 在将 Datomic 连接视为长期存在时需要考虑哪些挑战？
  • 在处理 JDBC 连接时，该方法是否普遍适用，还是仅适用于问题的子类（包括 Datomic 的）？
  • 我可以看到 Tomcat 的 JDBC 连接池在后台使用，从 Datomic 连接的角度来看，这个池是如何用于实现长寿命连接的？
  • 在实践中，您何时在幕后使用单独的 JDBC 连接，例如，您是否使用单独的连接进行读取和写入？
4

1 回答 1

0

“这取决于” ：）

例如，如果您设置了 memcached，则 Datomic 对等点可能根本不需要与 sql 数据库对话。Datomic 使用 sql 获取编码数据块，而不是进行结构化查询，因此如果 memcached 中存在块，则不需要 sql。此外，对等点将获得交易者发送给它的新块，因此如果您特别幸运，在您运行第一个查询之前，对等点中的所有内容都已经可用。

如果一个 chunk 不在 peer 中，并且不在 memcached 中，peer 需要连接到 sql 数据库获取 chunk。但这一切都发生在幕后，并且由您提到的tomcat连接池管理。通常，这个想法是，要成功运行查询，索引必须从存储中提取任何丢失的块（memcached、sql、...），而这以惰性方式发生。但是datomic连接本身“永远存在”，即这一切都是为您管理的，您不必根据对等方的流量等创建N个连接。

至于写入，那些通过交易者而不直接连接到存储。写入被表示为我们都熟悉的 EDN 数据结构（带有 db/add 等的列表列表），并被运送到事务处理者到队列并按顺序处理。然后交易者在需要时直接连接到存储，但这显然是一个单独的问题，不会以任何方式影响对等方。

我希望这是澄清:)

于 2021-03-06T11:34:31.043 回答