Closed delaneyj closed 6 years ago
The code is a bit complicated to follow. But, general sense is that your newBestFound
could be true, even if you didn't commit anything. If your had a ErrConflict in the txn which actually did the Set, and the next one just did a read and exited, it would end up printing your new best found if condition.
I doubt there's a bug in Badger, we have extensive tests for that. You should look deeper at your code.
newBestFound could be true, even if you didn't commit anything.
Not sure I follow. The newBestFound
is only set to true after a txn.Set()
call. If the set failed with an ErrConflict that flag will never be true.
The ErrConflict would be returned by txn.Update, not txn.Set. Update is the one which would try to commit the transaction, and run conflict detection. Set would just register what you intend to set.
Ah, that makes more sense. I don't think its in the README that the ErrConflict only happens at the txn.Commit(). I thought it would error out early. I can make this work now, thanks.
I'm pretty sure I must be using the txn.Update incorrectly. Basically I have a global best key that multiple go routines could possibly be updating. Have each in a loop if there is a conflict trying to update that record if its state it better. Weird thing is that global value bounces around...
So I made an MVP showing the problem.
Note the sequential version is fine. But the same routines don't work in goroutines.
I thought if the
bestKey
got updated the other transactions would invalidate and start over. What am I missing?