This is using the reactive java driver: On my local dev machine I just saw the following error:
`com.mongodb.MongoCommandException: Command failed with error 112 (WriteConflict): ‘WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction.’ on server 127.0.0.1:27017.
The full response is:
{“errorLabels”: [“TransientTransactionError”], “operationTime”: {“$timestamp”: {“t”: 1602354840, “i”: 5}}, “ok”: 0.0, “errmsg”: “WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction.”, “code”: 112, “codeName”: “WriteConflict”, “$clusterTime”: {“clusterTime”: {“$timestamp”: {“t”: 1602354840, “i”: 5}}, “signature”: {“hash”: {“$binary”: “AAAAAAAAAAAAAAAAAAAAAAAAAAA=”, “$type”: “00”}, “keyId”: {“$numberLong”: “0”}}}}`
I also checked the MongoDB log, but there wasn’t a single entry at the timestamp when the transaction failed. Is there any way to find out which query has caused the transaction to fail?
umm, just out of curiosity: why would that change anything if the driver only connects to a single node replica set?
However, I can unfortunately not try that easily, because I haven’t seen that exception ever since. Tried to replicate, doing the same things, but it never showed up again so far.
Our web clients (browser) connect to a web socket, which modifies the current user. There is a chance that this operation took place when a transaction (which also modifies the user document) was still running. Just a vague guess, but I haven’t found anything how I could check if this really is what has happened.
I was looking for easy first debugging steps, thinking along the lines of “If this happens a lot maybe it’s the volume of writes and there’s an inconsistency …”
But what you say … that there exists the possibility of a transaction interfering with another write … well, if you know that’s a possibility in your application, it certainly sounds like the first thing to look at.
Perhaps your code should handle exceptions and retry writes a few times in these instances.
thanks for your reply. It’s not happening a lot. I observed it running the full stack on my local machine, with me being the only active user (that’s why I am worried about it). I am used to being able to lookup what the cause of an aborted transaction is due to using mysql before. It’s quite a surprise to find out this seems to not be possible at all with MongoDB.
However, the main issue here is that I would like to confirm if my suspicion is accurate - however, it seems that’s currently not possible at all - as there seems to be no way to find out why exactly a transaction failed?
@st-h I do no know more details about the Java drivers or how to find the cause of an aborted transaction.
It’s quite a surprise to find out this seems to not be possible at all with MongoDB.
Yes, I ran into a similar frustration. I had 3 tables to which I added validation. 2 worked; 1 did not. I searched and determined definitively there’s no way to cause MongoDB to log why a validation failed. There’s an open issue to add that feature.
Edit: I did figure out my problem after exhaustive trial-and-error … a misspelling in one place
My takeaway is that, as good as MongoDB is, and I like it and use it daily, it’s not really “enterprise-ready”. It doesn’t have the completeness and stability of the mature relational products.
Hello
I have seens this error before.
Here is what i found as root cause for this. May be your scenario is different but still would like to share
The document we were trying to update was under Transactional block. So any document under transactional block if tried to be updated would give you this exact error
