RavenDB 在配置中使用OptimisticConcurrency?
有没有办法在 Raven.Server.exe.config 中将乐观并发设置为 true?或者,它可以以某种方式应用在数据库级别吗?在 RavenDB 的网站上,我看到几次提到设置 UseOptimisticConcurrency = true,但看起来它是在代码中的会话级别:
public void Save<T>(T objectToSave)
{
using (IDocumentSession session = Database.OpenSession())
{
session.Advanced.UseOptimisticConcurrency = true; // This is the setting
Guid eTag = (Guid)session.Advanced.GetEtagFor(objectToSave);
session.Store(objectToSave, eTag);
session.SaveChanges();
}
}
我想知道该设置是否存在于服务器范围内的某个地方,因此不需要在代码中为每个会话指定。
编辑:上面的代码产生以下错误。试图找出原因...
编辑 2:好的,我正在取得进展。如果我检索该对象,并在同一会话中调用 GetEtagFor(),那么我将获得有效的电子标签。所以我想我现在的主要问题是:在客户端 UI 中使用会话的正确方法是在应用程序启动时打开会话一次,然后在最后关闭它吗?还有...存储 eTag 的正确方法是什么?按照上面的编码方式,电子标签是在存储之前检索的,我认为这是错误的方法。我猜测应该在首次检索对象时检索 eTag。但是,当我们最初获取对象列表时,是否必须循环遍历每个对象并对它们调用 GetEtagFor() ?好像不太对劲...
Is there a way to set optimistic concurrency to true in Raven.Server.exe.config? Or, can it somehow be applied at the database level? On RavenDB's site, I see a couple of mentions of setting UseOptimisticConcurrency = true, but it looks like it's at the session level within the code:
public void Save<T>(T objectToSave)
{
using (IDocumentSession session = Database.OpenSession())
{
session.Advanced.UseOptimisticConcurrency = true; // This is the setting
Guid eTag = (Guid)session.Advanced.GetEtagFor(objectToSave);
session.Store(objectToSave, eTag);
session.SaveChanges();
}
}
I would like to know if it that setting exists somewhere server-wide, so it doesn't need to be specified for each session in code.
Edit: The code above produces the following error. Trying to find out why...
Edit 2: Ok, I'm making progress. If I retrieve the object, and call GetEtagFor() all within the same session, then I get a valid eTag. So I guess my main question now is: Is the correct way to use a session, within a client UI, to open the session once when the app starts, and then close it at the end? And... What's the correct way to store the eTag? The way it's coded above, the eTag is retrieved right before storing, which I would imagine is the wrong way to do it. I'm guessing the eTag should be retrieved when the object is first retrieved. But when we originally get a list of objects, should we have to loop through each and call GetEtagFor() on them? Doesn't seem right...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
鲍勃,
不,UseOptimisticConcurrency 是您打开会话时需要设置的内容。
不,整个应用程序只有一个会话是错误的做法。有关会话管理的更多详细信息,请参阅本文:
http://archive.msdn.microsoft.com/mag200912NHibernate
它讨论的是 NHibernate,但会话管理部分也适用于 ravendb。
Bob,
No, UseOptimisticConcurrency is something that you need to setup when you open the session.
And NO, a single session per the entire application is the wrong thing to do. See this article for more details on session management:
http://archive.msdn.microsoft.com/mag200912NHibernate
It talks about NHibernate, but the session management parts applies to ravendb as well.
免责声明:这不是推荐的方法,实际上打开 IDocumentSession 的做法是不好的,该 IDocumentSession 会随着客户端应用程序的存在而存在。有关替代解决方案,请参阅此处发布的答案:RavenDB Catch 22 - 乐观并发并查看其他客户端的变化。
看来我的乐观并发工作正常,所以我想我应该发布此内容以帮助其他人。
首先,在 DataAccessLayerBase 中,我初始化 DocumentStore 和 IDocumentSession。只要客户端应用程序正在运行,它们就会打开并使用。
接下来,检索数据时,使用现有会话:
最后,保存时,获取eTag并保存。
如果 UI 的另一个实例正在运行并更改对象,则会发生并发异常。这就是我们想要的。
我刚刚再次查看了这篇文章的标题,并意识到这并没有回答如何在服务器配置文件中设置并发的问题。不过,由于现在可以在数据层中设置一次,这对我来说已经足够了。
Disclaimer: This is not a recommended approach, and in fact bad practice to open an IDocumentSession that will live as long as the client app lives. For an alternate solution, see the answer posted here: RavenDB Catch 22 - Optimistic Concurrency AND Seeing Changes from Other Clients.
It looks like I got optimistic concurrency working, so I thought I'd post this to help any else.
First, in DataAccessLayerBase, I initialize the DocumentStore and IDocumentSession. These will be open and used as long as the client app is running.
Next, when retrieving the data, use the existing session:
Finally, when saving, get the eTag and save.
If another instance of the UI is running, and changes the object, a concurrency exception will occur. And that's what we wanted.
I just looked at the title of this post again, and realized this doesn't answer the question of how to set concurrency in the server config file. However, since it can now be set once in the data layer, that's good enough for me.