抑制只读 EF 上下文的 TransactionScope 登记？

发布于 2024-09-15 20:03:57 字数 164 浏览 12 评论 0原文

我有一个场景，我需要打开多个指向不同数据库的数据上下文。不过，我只写入其中一个数据库并从其他数据库读取......因此从技术上讲，事务应该只针对其中一个数据库。

我想避免将 TransactionScope 升级为分布式事务，这样我就不必担心 MSDTC ...有没有办法让事务中只登记一个上下文？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

绅刃 2024-09-22 20:03:57

我不确定这是否会将第二个连接纳入事务中，但您可以尝试抑制您选择的事务范围：

using (new TransactionScope(TransactionScopeOption.Suppress))
{}

I'm not sure if this will enlist the the second connection into the transaction, but you can try to suppress the transactionscope on your select:

using (new TransactionScope(TransactionScopeOption.Suppress))
{}

回复收藏 0 原文

末蓝 2024-09-22 20:03:57

我一直在研究 Linq to Sql 的类似问题 - 最初我们的解决方案是每个请求使用相同的连接。 Rick Strahl 就此发表了一系列值得一看的博客文章。

在我们的解决方案中，DataContext 构造函数有一个重载的构造函数，用于从工厂检索连接（如果不存在连接，则传递的连接存储在线程上）

public DataContext1(connection)
    : base (ConnectionFactory.GetConnectionFromContext(connection))
{
}

这似乎在 WCF 场景中工作正常，连接工厂可以存储/ 从 ServiceModel.OperationContext.Items 集合中检索，并且（更重要的是）订阅 OperationComplete 事件，以便在完成所有操作时关闭/释放线程上的连接。

我发现我们还需要扩展连接对象，以便在处置拥有的数据上下文时（例如，在每个操作范围完成后），可以防止内部连接的自动关闭/处置。

我现在正在研究非 WCF 场景...老实说，它并不漂亮。我们也没有 WCF 上下文中的“OperationCompleted”事件触发器。

I have been looking at a similar issue with Linq to Sql - initially our solution is to use the same connection per request. Rick Strahl has done a series of blog posts on this which were worth looking at.

In our solution the DataContext constructor(s) have an overloaded constructor that retrieves the connection from a factory (if no connection exists, the connection passed is stored on the thread)

public DataContext1(connection)
    : base (ConnectionFactory.GetConnectionFromContext(connection))
{
}

This seems to work fine in a WCF scenario, the connection factory can store / retrieve from the ServiceModel.OperationContext.Items collection, and (more importantly) subscribe to the OperationComplete event in order to Close / Dispose the connection on the thread when all operations are done.

I found that we also needed to extend the connection object such that you can prevent automatic closure / diposal of the internal connection when the owning datacontext is disposed (e.g. after each operation scope completes).

I'm looking at the non-WCF scenarios now... TBH it's not pretty. We also don't have the 'OperationCompleted' event trigger that's there in the WCF context.

回复收藏 0 原文

~没有更多了~