长期运行的交易结构化方法
我正在寻找一种结构化的方法来处理长期运行（数小时或更长时间）的事务。正如此处所述，这些类型的交互通常由乐观处理锁定和手动合并策略。
使用标准事务处理此类问题的更结构化的方法将非常方便。各种长时间运行的交互，例如用户注册、订单确认等，都具有类似事务的语义，并且发明自己的脆弱的手动回滚和/或超时/清理策略既容易出错又乏味。
以 RDBMS 为例，我意识到这将是与保持所有事务打开相关的主要性能成本。作为替代方案，我可以想象有一个数据库同时支持两种隔离级别/策略，一个用于短期运行，一个用于长期运行的对话。例如，长时间运行的对话可以对数据访问有更严格的限制，以方便他们花费更多时间（某些数据的只读语义、乐观锁定语义等）。
有没有可以做类似事情的解决方案？
I'm looking for a structured approach to long-running (hours or more) transactions. As mentioned here, these type of interactions are usually handled by optimistic locking and manual merge strategies.
It would be very handy to have some more structured approach to this type of problem using standard transactions. Various long-running interactions such as user registration, order confirmation etc. all have transaction-like semantics, and it is both error-prone and tedious to invent your own fragile manual roll-back and/or time-out/clean-up strategies.
Taking a RDBMS as an example, I realize that it would be a major performance cost associated with keeping all the transactions open. As an alternative, I could imagine having a database supporting two isolation levels/strategies simultaneously, one for short-running and one for long-running conversations. Long-running conversations could then for instance have more strict limitations on data access to facilitate them taking more time (read-only semantics on some data, optimistic locking semantics etc).
Are there any solutions which could do something similar?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
RDBMS ACID 事务始终属于短的、原子的和本地操作。分布式应用程序、自治服务、松散耦合组件使用不同的策略，例如保留和补偿事务。
关于此主题的好读物是 Pat Helland 的论文，他自 80 年代以来一直在教授该主题。例如，请参阅自治应用程序的架构或封地和使者。
RDBMS ACID transactions belong always to short, atomic and local operations. Distributed application, autonomus services, loosely coupled components use different strategies like rentention and compensating transactions.
A good read on this topic are Pat Helland's papers, he's been teaching about this subject since the 80s. See for instance Architecture of an Autonomous Application or Fiefdoms and Emissaries.
我宁愿使用 BPM 工具来处理此类事情，它明确旨在支持长期运行的编排。我无法详细说明，但建议检查了解 BPM 服务器。我引用了下面的一些部分，但整篇论文值得一读：
I'd rather use a BPM tool for such kind of things, there are explicitly intended to support long-running orchestrations. I can't elaborate right but suggest to check Understanding BPM Servers. I'm quoting some parts below but the whole paper is worth the read: