为一个事务执行了118SQL语句
最近，我们正在为我们的应用程序解决一个性能问题，该代码最初是基于Corda教程代码的M13版本构建的，我们遵循了Corda的版本，现在更新为V2.0。业务很简单，甲方以表单的形式上传一份包含一些元数据的合同文档，然后将此事务发送给乙方，我们在验证功能中定义了一些简单的条件，因此，通常事务将在没有任何手动操作的情况下完成。但如果我们在本地环境中这样做，这个过程大约需要3秒钟（一个2.9M附件），但当我们将其部署到我们的开发环境中时，H2托管在与CorDapp不同的服务器中，通常需要15-20秒才能完成，只需一个公证节点。
我们尝试启用H2跟踪日志功能，从日志中，我们发现执行了165条SQL语句，包括114次选择、31次插入、16次删除、2次更新和2次修改。我们的流与教程的代码基本相似，除了接受流之外，我们具有与发起流类似的验证功能，并且我们有附件，但教程没有。
使用相同的方法，我在基于V1.0的Corda示例代码上执行了一个create IOU事务(因为没有V2.0示例代码，所以我只能在V1.0上执行)，对于该事务，执行了118条SQL语句，包括74条选择、28条插入、14条删除和2条更新。
还有很多“SET LOCK_MODE”和 COMMIT，检查点经常被删除和插入。因此，我们希望收到您对以下问题的意见，请对此提供帮助。谢谢。
对于一个事务来说，这些如此多的SQL执行是否合理，并且这些必须发生才能完成一个事务？由于我们可能无法理解每个SQL执行的目的是什么，因此您对我们下一步应该做什么以获取其根本原因有任何建议吗？当我们在不同的服务器上分别托管H2数据库和公证人时，事务的15-20秒是正常的吗？我们的CorDapp（甲方、乙方和公证人）、H2数据库分别托管在Azure VM上。
共有1个答案
迄今为止，Corda的工作更多地关注功能而不是性能。在数据库和其他地方有许多性能改进将在未来的版本中实现。
但是，交易没有理由需要15-20秒。
您运行了多少次交易？我这样问是因为每当一个节点看到一个新的附件作为事务的一部分时，它都会缓存它并存储起来供以后参考。这意味着大型附件只需要在第一个事务中通过网络发送。如果您发送10个引用同一个附件的事务，它只会在第一次被下载，其他9次会快得多。你观察到这些改进了吗？
-
问题内容： 我正在一个Java应用程序中工作，我需要同时执行这两个查询（如Java中的Strings），并在出现错误的地方回滚事务。 更新 我创建了一个字符串，其中两个查询用注释建议分隔开 更新 我已经尝试了JDBC原子事务作为Java中的代码。我强迫第二个sql失败，但是即使我指定.setAutoCommit（false）; dblink通过第一个查询影响了另一个数据库。我在没有dblink事务
-
我需要创建一个具有架构列表的@Scheduled方法，对于每个架构，从2个表中删除行。 我将deleteFromCustomerTables定义为@Transactional（propagation=propagation.REQUIRES_NEW），并在其中使用EntityManager从2个表中删除行。 为了使其工作，我需要将@Transactional添加到计划FixedDelayTask，
-
在Liquibase论坛的一次讨论中，开发人员Nathan Voxland说Liquibase应该在每个变更集之后提交。我知道这是一个七年前的线程，所以从那以后可能发生了很多变化，但也许没有？ 它应该在变更集之后提交。在大多数数据库上，addColumn也会自动提交。 changeSet标记的文档可以解释为“在changelog中的所有前提条件成功之后提交”，这与7年前的帖子相矛盾。 我有一个ma
-
问题内容： 我有一张桌子，里面有人和他们拥有的汽车 该查询为我提供了和拥有完全相同的汽车以及Lisa本人的人，这很好。 结果： 如果我想查找所有拥有相同汽车的人，请重新运行查询，结果应为我。 现在，我有一个Java名称列表，对于每个名称，我都运行此查询。真的很慢。无论如何，是否可以找到所有拥有相同汽车的人，并在单个数据库调用中将结果划分为组？ 例如，使用第一个表。我可以运行将名称分组的查询。请注意
-
问题内容： 为了了解Spring事务的工作原理，我想知道在以下情况下发生的情况：如果一种方法标记为，而另一种方法标记为。 假设配置使用所有默认设置。 现在，如果我要输入，显然可以开始交易。然后，钻进去会发生什么？交易已经存在的事实会导致没有新的交易诞生，还是我在这里创建两个交易？ 关于Propagation的文档（在下面引用）似乎涵盖了这一点，但是我想验证一下我的理解 Propagation：通常
-
问题内容： 如果表myTable包含100000000条记录。 而且我执行时没有开始事务，并且出现了问题，例如服务器电源故障。 会删除一些记录吗？ 问题答案： 否，如果数据库引擎符合ACID。 任何单个写操作都是 Atomic ，无论是否包含在显式事务中。 又称每个写操作是一个自包含的事务。