在水壶中运行转换时，如果出现错误，则有时会使整个转换的效果回滚。如果您的数据库系统支持事务，则Kettle可以利用该功能在失败时启用回滚。通过在转换设置对话框的“其他”选项卡上启用“生成转换数据库事务”复选框，可以在水壶中激活事务行为。本文解释了此功能的用途，以及它在其他情况下的用途。
仔细看看默认行为
如果关闭“make transformation database transactional”功能（缺省值），则使用数据库的步骤的每个副本都会创建并维护自己与数据库的连接。考虑一个适用于示例数据库“MyData”的简单转换。该转换从表中读取记录，转换某些字段并更新原始表中的记录。这通常会使用表格输入步骤，一些转换步骤和更新步骤完成。表格输入和更新步骤都将使用相同的数据库定义“MyData”。运行转换时，每个步骤都保持自己与“MyData”数据库的连接。
这通常是一件好事，因为大多数数据库系统的设计都考虑了并发连接，并且转换通常在并行运行db查询时执行得最快。
启用交易模式
但在某些情况下，默认的并行模型可能不是最佳选择。启用“交易”功能有两个作用：
- 所有使用数据库的步骤都共享一个连接。
- 每个连接在打开时都会开始一个事务。如果转换成功完成，则事务将被提交。如果转换遇到错误并且过早结束，它将回滚。
共享数据库连接通常意味着转换执行速度稍慢。使用数据库的步骤竞争与它的连接，并且必要的同步有一些开销。但它也使一些有趣的可能性。显而易见的是整个转型具有交易属性。就数据库而言，转换完全执行或根本不执行。这个特性在增量加载场景中非常有用，例如：在数据库出现意外出错的情况下，让数据库回滚整个转换的效果是一个好主意，而不必担心如何手动将数据库恢复到原始状态重试负载。但除了这个很酷的功能之外，还有其他一些效果值得一提。
写和重读记录
水壶初学者有时很难理解为什么他们不能一步写出记录，并在相同的转换过程中更可靠地在下游进行查看。这是因为在默认模式下写入步骤和查找步骤创建自己的数据库连接，写入步骤通常设置为以相当大的批量写入。如果启用“事务性”模式，则数据库连接将被共享。因此，如果写入步骤配置为批量大小为1（即时查询执行），则可以在转换的下一个步骤中可靠地查找写入的记录：没有并发问题，没有延迟查询造成的问题。有人可能会认为，利用这一事实进行转换的设计并不完善（大多数情况下它们可能不是），
并发修改
我有时会看到转换，这些转换会在单独的更新步骤中更新相同的记录（可能是它们的不同字段）。在默认模式下，这可能会导致零星的死锁情况。假设这两个步骤都尝试在并发执行批次中更改相同的记录。根据数据库系统的不同，这可能会导致死锁（有希望不会导致系统停顿，但会被RDBMS检测到）。这种情况也可以通过将数据库连接设置为“事务性”来弥补。事实上，使用单个连接会阻止并发批处理的执行，所以永远不会发生死锁。同样，最好不要设计围绕该事实的转换，而是尝试收集对记录的所有更改并仅更新每条记录一次。但是，如果您需要快速修复受此影响的转换，
2728
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
