Concurrency Exception again

[lunarjetset]

After deploying a fix I'm getting a Concurrency Exception again - it only happens very rarely and I can't reproduce it.

Is there any way to log the actual document that is getting the Concurrency issue - as that would really help debug this.

Thanks

Pete

[Oren Eini (Ayende Rahien)]

You can enable debug logging, sure.

https://ravendb.net/docs/server/deployment/docs-debug-logging 

Note that concurrency exception is expected when you are running in UseOptimisticconcurrency = true

[Pete Nelson]

Thanks Oren - scared to enable that on the live server though which is
the only place that is getting these.

BUT: if you say it's expected and we catch it and deal with it then I
guess it's not doing to do any harm (except the last user won't get
their write - which actually doesn't matter for this app)

[Chris Marisic]

It's up to you to decide what a concurrency exception means. You can either reject the write (easiest), or you can attempt to merge the changes into the newest document (not exceedingly hard, but can lead to unintended consequences), dump the documents into a conflict resolution queue that a human will then parse the correct state of the object (hardest/most work)

[lunarjetset]

thanks Chris - good advice.  When you say reject the write - do you mean just catch the exception and move on?  Or is there a better way?

[Matt Warren]

Yeah, if you just catch the exception and move on, that means you are rejecting that particular write. That's the easiest way of handling issues with concurrent writes because the RavenDB api does most of the work for you, you just have to catch the exception.

[Pete Nelson]

thanks Matt

[Chris Marisic]

Generally if you're going to go with rejecting the write, you want to inform the user that submitted that as best as possible.

On a more global level, my goals with usage of RavenDB is to hook in SignalR between the html client & MVC3 server such that if anyone modifies documents that other users have open in their browsers that they'll either get full change information immediately, or at the very least be informed preemptively that the document has changed and it needs to be reloaded before editing can continue. As opposed for them to do their work completely, THEN find out it's rejected.

[Pete Nelson]

sounds really interesting!

[jamesfarrer]

Hi Chris,

This sounds a really interesting approach. If you fancy writing a blog post on what you're doing then that would be wonderful!

James

[Tom Cabanski]

Your problem domain must be incredibly collaborative to demand the complexity of the kind of solution you're suggesting.  Is it really common for two users to be changing the same data element at roughly the same time in your domain? 

[Oren Eini (Ayende Rahien)]

Chris,

Note that this is a planned 1.2 feature.

[Chris Marisic]

What exactly is a 1.2 feature?

[Oren Eini (Ayende Rahien)]

A feature that is planned for 1.2 release

[Chris Marisic]

What exactly is the feature you're saying is in 1.2

[Oren Eini (Ayende Rahien)]

Notifications for changes in the db.

[Chris Marisic]

Not that I'm diminishing the importance of those notifications as there are many scenarios that they will matter for, however for the described scenario:

user1 on abc
user2 on abc

user2 modifies abc

tell user1 abc has been modified

The change notification from the database doesn't go far for telling user1. This would still likely involve SignalR (not saying this is Raven's responsibility just stating this) so that I could inform the client for user1. Now this theoretically could be VERY easy with signalR + raven change notifications because I store my documents using IDs that are the actual true URL slugs to access the resource through REST so it could potentially be very easy to find all clients that are connected to "mydoc/abc"

This seems like a very logical seperation of concerns for Raven to not take a full on dependency to signalR but provide the tools (change notifications) to make working with SignalR very straightforward. Instead of the current scenario where you'd need to hold some kind of dictionary for every user of what documents they have open, and then when any document changes trying to walk all users dictionaries to find if any contain that, then obviously keeping the dictionaries up to date etc.

[Oren Eini (Ayende Rahien)]

Chris,

The problem that I am trying to prevent is the need to do polling to _get_ the recent changes.