New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] DataRace Exception, possible bug #150
Comments
Please see: #116 Does the |
Thanks for the suggestion, but not exactly, I have force update in the code, and I still get this exception. Let me give you an example:
The usage:
This is very similar mechanism I am using with rom. There are other usages with I ran into the same data race exceptions. The goal would be:
If we would have an option to skip
and check with last updated timestamps instead the data race, that would help a lot. I can try to put together a small example project, if it helps. The reason I just not deleting that check, that I may get some bad side effects in real data race conditions. |
To sum up: "sometimes you don't care about what is there, and you just want to overwrite". Indeed, in cases where you don't care about overwriting data (because you don't care, or because you know there isn't a race condition), updating your local entity repeatedly will do more round trips than necessary, and will induce more latency, especially for commonly accessed entities. use a lock (what Josiah would do)However, I'm not feeling great about adding a feature to disable the safety I added in order to prevent data and index corruption. If you wanted to ensure that this never happens, you could use an explicit lock. Lock around the object, fetch/refresh, update local object, write, unlock. That guarantees that your round trips / delays are all up front in the lock, not in the write / update. It also gives you the ability to "deadline" the changes, so if it takes longer than a certain period of time, bail out. That makes sure that everything that I care about WRT data integrity is upheld. That's what I would recommend.
With a little effort, you can turn the above 5x IOs (get + lock acquire + refresh + save + release) into 4 (lock acquire, get, save, release). OR ignore most of the internals (you can do this, but you might break stuff)Alternatively, if you're not indexing this data at all, and don't care about data integrity (seems like it), you can always do the following on some encoded data:
This does 2 round trips. With a bit more effort, you can get that primary key in advance for anything, and call the model's So, 1 - 5 round trips, depending on safety level / perf optimizations. Does that work? |
Hi,
Currently the writer checks for data race with:
But, if the use case, the above will thow exception (return race):
So if the second writer send an object, after the first one has already saved, it will return an error without reason.
Question:
Do I need this check in update only environments? Or what would be the good check in our case?
There can be cases when both writer stuck in a place and doesn't update after a point, even with force save.
Couldn't be a better way to use timestamp as identifier of which update is the newer and the above check would be useful only if the object were deleted?
Thank you for the answers.
The text was updated successfully, but these errors were encountered: