当 TransactionScope 和嵌套事务都不支持时怎么办？
TransactionScope 是一个令人惊叹的功能，但正确实现它的提供商太少了。 我不想将连接作为参数传递。
TransactionScope is an amazing feature but too few providers do implement it correctly.
I don't want to pass the connection as parameter.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不确定您想在这里使用 TransactionScope 实现什么目标 - 如果想法是跨方法实现事务的自动流（以及正在进行的事务中的简单登记），那么将连接作为参数传递并不是唯一的方法。您可以使用当前 CallContext< 传递当前连接和事务/a> （或当前线程）。放置一个简单的静态包装器，用于检查当前调用上下文中是否存在连接/事务，如果不存在则创建。与通过参数传递相反，这是透明的非侵入式方式。
现在，如果您正在考虑跨应用程序域边界流动事务和/或使用多个资源管理器（即使用分布式事务），那么最好的选择是使用 TransactionScope 并推出 您自己的资源管理器。当然，这不是一件小事，但这就是要求所需要的。如果底层系统不提供事务资源，则自定义资源管理器可以使用补偿事务来进行回滚（例如，文件系统顶部的管理器可以使用“删除文件夹”作为针对“创建文件夹”的原始事务的补偿事务） 。
Not sure what you wanted to achieve using TransactionScope here - if idea is to have auotmatic flow of transactions across methods (and simple enlistment within ongoing transaction) then passing connection as parameter is not the only way. You can pass current connection and transaction using current CallContext (or Current Thread). Put a simple static wrapper that would check if connection/transaction exists on current call context and creates if not. This is transparent non-intrusive way as opposed to passing by parameter.
Now, if you are looking at flowing transactions across app domain boundaries and/or using multiple resource managers (i.e. using distributed transactions) then the best bet would be to use TransactionScope and roll out your own ResourceManager. Of course, this is not a trivial thing but then that's what the requirement entails. If underlying system does not provide transactional resource then custom resource manager can use compensating transaction for having roll backs (for example, a manager on a top of file system can use "Delete Folder" as compensating transaction against original transaction of "Create Folder").
也许您正在寻找系统流行率。
基本上，每笔交易都会记录（保存交易的详细信息），并且如果应用程序崩溃并重新启动后，您可以从上次中断的位置继续操作，也可以根据日志状态回滚更改。
以下是快照模式的链接，可以帮助您实现系统普遍性。
Maybe you're looking for System Prevalence.
Basically, every transaction is journaled (the details of the transaction are saved) and if the application crashes and is restarted you can either pick up where you left off or rollback the changes based on the journaled state.
Here's a link to the Snapshot pattern that can aid you in implementing System Prevalence.