db4o客户端查看来自另一个客户端的更改

我正在运行一个db4o服务器，有多个客户端访问它。我刚刚遇到一个客户没有看到另一个客户的变化的问题。从我在网上的研究来看，基本上有两种方法可以解决这个问题

1:对对象调用Refresh（）（从）：

常数int activationDeph=4

client2.Ext（）.Refresh（objFromClient2，activationDeph）

2：不是缓存IObjectContainer，而是为每个DB请求打开一个新的IObjectContainer

是这样吗

是的，#1效率更高，但指定要刷新的对象真的现实吗？我的意思是，当涉及数据库时，每次客户端访问它时，它都应该获得最新的信息。这就是我倾向于2的原因。另外，我也不担心效率问题

那么，这两种方法对吗？还是还有别的

等等。。。当对象超出范围时会发生什么情况？在计时器上，我调用一个从DB服务器获取对象的方法。该方法实例化对象。由于对象超出范围，因此无法刷新。当我调用DB时，我看不到来自客户端的更改。在这种情况下，似乎唯一的选择是打开一个新的IObjectContainer。没有

**编辑**

我想我应该使用我最终决定使用的解决方案发布一些代码。由于在每次调用中使用新的IObjectContainer会带来一些严重的复杂性，因此我将在访问DB的每个方法中执行一个Refresh（）（请参见下面的Refresh（）行）。因为我已经将DB访问封装到了逻辑类中，所以我可以确保每次都在那里执行Refresh（）。我刚刚测试了这个，它似乎在工作

注意：下面的数据库变量是db4o IObjectContainer的变量

public static ApplicationServer GetByName(string serverName)
{
    ApplicationServer appServer = (from ApplicationServer server in Database
                                   where server.Name.ToUpperInvariant() == serverName.ToUpperInvariant()
                                   select server).FirstOrDefault();

    Database.Ext().Refresh(appServer, 10);

    return appServer;
}

1） 正如您所说的，主要问题是您通常不知道要刷新哪些对象。 您可以在任何客户端提交后立即使用c刷新对象。db4o将分发该事件。请注意，这也会消耗一些网络流量和发送事件的时间。并且会有一个时间范围，在这个时间范围内，您的对象会处于过时状态

2） 它实际上是最干净的方法，但不是针对每个db请求。为每个逻辑工作单元使用对象容器。在业务操作中作为一个“原子”工作单元的任何操作

总之，总的来说。db4o从来都不是以客户机-服务器场景作为第一优先级构建的，它显示在并发场景中。您无法避免使用陈旧（甚至不一致）的对象状态，并且没有并发控制选项（低级别信号量除外）

---

我的建议是：每个工作单元使用一个客户端容器。请注意，即使这样，您也可能会得到过时的数据，这可能会导致视图和更新不一致。当您的应用程序场景中很少出现任何争用和竞争，并且您可以偶尔容忍一次错误时，这就可以了。但是，如果您确实需要确保正确性，那么我建议使用一个具有更好并发存储的数据库=（

谢谢，Gamlor。在花费了这么多时间在db4o上之后，这很难接受：“…您可以偶尔容忍一个错误…”如果出现错误，DB怎么能被考虑使用呢？我已经创建了一个db4o服务器，以及两个使用它的不同应用程序。不知道现在该怎么做。RavenDB？其他什么？你真的需要100%的绝对正确性吗？大多数应用程序不需要它（金融应用程序需要它）。因此，上述选项可能“足够好”。但正如所说，这实际上取决于应用程序。当然，您可以使用db4o解决这些问题，但它变得非常快和困难。对RavenDB来说：RavenDB当然是一个非常好的文档数据库。请注意，RavenDB per default还允许返回状态结果。但是它更容易控制陈旧性，并且具有乐观锁定支持。我想说，没有100%的正确性可能是灾难性的。我正在创建一个自动部署应用程序。如果用户更改了应用程序服务器应该使用的连接字符串，而应用程序服务器在更新自己时看不到该更改，那就不行了od.选项2有些复杂。如果我们使用一个IObjectContainer来检索一个对象，然后使用另一个IObjectContainer来保存它，这是行不通的。新的IObjectContainer将向数据库中添加一个新对象，而不是保存现有的对象。是时候尝试并思考一个优雅的解决方案了…@更新场景：我认为典型的场景在ario中，您可以接受一些暂时的不一致。当然，这种情况应该很少发生，并且能够从暂时的不一致中恢复。但是您当然需要一些刷新策略，如上面显示的回调机制。