LiteDB中共享连接模式下的迭代器陷阱与解决方案

问题现象

在使用LiteDB数据库时，开发者可能会遇到一个奇怪的现象：当数据库以共享连接模式(ConnectionType.Shared)打开时，对集合进行迭代操作并在迭代过程中执行更新操作会导致"Engine instance already disposed"异常。而在直接连接模式(ConnectionType.Direct)下，同样的代码却能正常工作。

问题复现

让我们通过一个典型的使用场景来说明这个问题：

using LiteDatabase Database = new(new ConnectionString() {
    Filename = "Database.db",
    Connection = ConnectionType.Shared,
});
ILiteCollection<BsonDocument> Accounts = Database.GetCollection("Accounts");
foreach (BsonDocument Document in Accounts.FindAll()) {
    Accounts.Update(Document);
}

当执行上述代码时，系统会抛出LiteException异常，提示"Engine instance already disposed"。

问题分析

这个问题的根源在于LiteDB在共享连接模式下对数据库引擎实例的管理方式。在共享模式下：

1. 每次数据库操作都会获取一个新的引擎实例
2. 操作完成后，引擎实例会被立即释放
3. 当使用迭代器(IEnumerable)时，每次MoveNext()都会触发新的操作
4. 在迭代过程中执行更新操作会导致引擎实例被意外释放

解决方案

开发者可以采用以下几种方式解决这个问题：

1. 强制立即执行查询

将查询结果转换为列表，强制立即执行所有查询操作：

foreach (BsonDocument Document in Accounts.FindAll().ToList()) {
    Accounts.Update(Document);
}

2. 使用直接连接模式

如果应用场景允许，可以使用直接连接模式：

Connection = ConnectionType.Direct

3. 避免在迭代中执行更新操作

重构代码逻辑，将查询和更新操作分离：

var documents = Accounts.FindAll().ToList();
foreach (var doc in documents) {
    // 修改文档
    Accounts.Update(doc);
}

最佳实践建议

1. 对于需要频繁读写操作的场景，优先考虑使用直接连接模式
2. 在共享模式下操作时，尽量将查询结果物化为列表后再处理
3. 避免在迭代过程中执行可能导致引擎状态变化的操作
4. 对于复杂的业务逻辑，考虑使用事务来保证操作的原子性

技术原理深入

LiteDB的共享连接模式设计初衷是为了支持多进程/多线程并发访问。在这种模式下：

• 每个操作都是独立的
• 引擎实例的生命周期严格限定在单个操作内
• 迭代器的延迟执行特性与这种设计产生了冲突

当我们在迭代过程中执行更新操作时，实际上是在一个尚未完成的迭代过程中启动了新的数据库操作，这会导致前一个操作的引擎实例被意外释放。

总结

理解LiteDB在不同连接模式下的行为差异对于构建稳定的应用程序至关重要。特别是在共享连接模式下，开发者需要特别注意操作的生命周期管理。通过本文介绍的方法，可以有效避免这类问题，确保应用程序的稳定运行。