我正在寻找一种结构化的方法来处理长时间（数小时或更长时间）的交易。正如这里提到的，这些类型的交互通常由乐观锁定和手动合并策略来处理。
使用标准事务对此类问题采取更结构化的方法会非常方便。各种长时间运行的交互，例如用户注册、订单确认等，都具有类似事务的语义，并且发明自己脆弱的手动回滚和/或超时/清理策略既容易出错又乏味.
以 RDBMS 为例，我意识到这将是与保持所有事务开放相关的主要性能成本。作为替代方案，我可以想象拥有一个同时支持两种隔离级别/策略的数据库，一种用于短期运行，一种用于长期运行的对话。例如，长时间运行的对话可能对数据访问有更严格的限制，以方便他们花费更多时间（某些数据的只读语义、乐观锁定语义等）。
有没有可以做类似事情的解决方案？
我宁愿使用 BPM 工具来处理这类事情，它们明确旨在支持长期运行的编排。我无法详细说明，但建议检查Understanding BPM Servers。我在下面引用了一些部分，但整篇论文都值得一读：
管理编排的状态
编排与其使用的业务服务之间的最大区别之一是每个服务的执行时间。对典型服务的请求会在几秒钟内生成回复。但是，因为它通常驱动全部或部分业务流程，所以编排可能会运行数小时、数天或数周，具体取决于流程完成所需的时间。例如，如果在流程中的某个时刻需要人工批准，而必须给予她批准的人正在休假，该怎么办？因为业务流程可能需要很长时间才能完成，所以控制它们的编排也可能运行很长时间。
这种长期运行的性质会影响编排如何管理它所维护的有关正在运行的进程的内存信息（状态）。如果编排在很长一段时间内被阻塞，那么将这种状态保存在内存中没有多大意义。相反，BPM 服务器应该为编排状态自动写入磁盘提供一种方式，然后在业务流程恢复时再次恢复，即使是几天或几周后。
状态管理说明了 BPM 服务器和应用程序服务器之间的另一个显着区别。由于支持长期运行的业务流程不是它们的主要目的，应用服务器传统上没有处理这种状态管理。但是，因为它们明确旨在支持长时间运行的编排，所以 BPM 服务器确实提供了这种服务。
处理交易
许多业务流程需要以事务为特征的全有或全无行为。例如，驱动业务流程的编排可能需要调用两个业务服务并确保两个请求都成功或都失败。这种原子事务可以使用标准的两阶段提交协议来完成，这是 BPM 服务器通常支持的。事实上，应用程序服务器包含此功能，因此构建在应用程序服务器上的 BPM 服务器可以很容易地提供此功能。
然而，许多业务流程的性质引发了另一个问题。如果一个特定的进程需要全有或全无的行为，但传统的原子事务是不可能的怎么办？原子事务需要在事务的整个生命周期内锁定数据，这在事务很短时不是问题。但是假设必须捆绑到一个全有或全无的组中的服务包括需要人工批准的服务。即使所需的批准者没有休假，一个人做出响应所需的时间也可能太长，以至于数据无法保持锁定状态。或者，如果必须在此事务组中的一项服务不参与原子事务怎么办？这不是一个牵强的担心，因为许多应用程序不会让任意客户端锁定他们的数据。
为了处理此类情况，BPM 服务器支持长时间运行的事务。也称为业务活动和其他名称，长时间运行的事务不是通过回滚所有更新来处理错误，而是通过在发生错误时执行某种补偿逻辑来处理错误。例如，假设一个特定的长时间运行的事务包括一个原子事务，该事务将资金从一个银行转移到另一个银行，然后是一个在转移成功后执行另一个应用程序的操作。如果此最终操作失败，则业务流程的逻辑要求撤消汇款。然而执行这个传输的原子事务已经提交了——它怎么能被撤销呢？答案是，如果发生故障，补偿逻辑必须运行，可能执行另一个原子事务以撤消传输影响的逻辑。BPM 服务器提供内置工具，允许编排的创建者定义此补偿操作，然后在长时间运行的事务失败时自动执行。
虽然在不可能进行原子事务时补偿很有用，但也不是没有问题。例如，假设一个编排在一个长时间运行的事务的早期部分修改了一些数据，然后运行一个补偿操作以将这些数据改回其原始状态。如果其他一些应用程序在这两个事件之间访问该数据会发生什么？第二个应用程序很可能使用最终被认为在制定业务决策时不正确的数据，例如计算信用风险。或者考虑一下没有明显补偿的操作。如果编排导致导弹发射，则无法通过该编排中的补偿代码来扭转这种情况。然而，虽然补偿并不是一个完美的解决方案，
RDBMS ACID 事务总是属于短的、原子的和本地的操作。分布式应用程序、自治服务、松散耦合的组件使用不同的策略，如保留和补偿事务。
关于这个主题的好读物是Pat Helland 的论文，他自 80 年代以来一直在教授这个主题。例如，请参见自治应用程序的体系结构或Fiefdoms 和 Emissaries。