DbContext生命周期内保持连接：显式调用OpenConnection是否有弊端？

你的理解是否正确？ #

完全正确。

EF（包括EF Core和EF6）默认的连接管理逻辑是：每次执行查询时从连接池获取连接，查询执行完成后立即将连接释放回连接池。而PostgreSQL的advisory锁是与数据库连接绑定的，一旦连接被释放，锁会自动失效。

你第一次调用SqlQuery获取锁后，连接被释放回池；后续执行ctx.Outbox.Where查询时，EF会从连接池取出新的连接，自然无法继承之前的锁。显式调用ctx.Database.OpenConnection()会强制DbContext持续持有该连接，直到上下文被释放（比如using块结束），后续所有查询都会复用这个连接，因此advisory锁能保持有效。

显式调用OpenConnection()的弊端 #

• 连接占用时间延长：原本查询完成就释放的连接，现在会被持有到DbContext销毁。高并发场景下，大量长时间占用的连接可能导致连接池耗尽，引发新请求等待连接的问题。
• 泄漏风险：如果没有正确释放DbContext（比如遗漏using块、异常导致上下文未被Dispose），连接可能被长期占用甚至泄漏，进一步加剧连接池压力。
• 连接复用效率降低：即使后续操作不需要持锁，也会占用同一个连接，无法让连接及时回到池子里供其他请求复用。

更优的替代方案 #

可以将锁操作与后续业务逻辑放在同一个事务中，EF在事务期间会自动保持连接，无需显式调用OpenConnection()：

using var transaction = ctx.Database.BeginTransaction();
try
{
    var canLock = ctx.Database.SqlQuery<bool>($"SELECT pg_try_advisory_lock(42) as \"Value\"").FirstOrDefault();
    if (!canLock)
    {
        transaction.Rollback();
        return;
    }

    var outboxMessages = ctx.Outbox.Where(...).ToList();
    // 执行其他业务逻辑

    transaction.Commit();
}
catch (Exception)
{
    transaction.Rollback();
    throw;
}

事务结束后，连接会被自动释放回连接池，既保证了锁的有效性，又避免了长期占用连接的问题。

内容的提问来源于stack exchange，提问作者Magnus