Couchbase attempt context transaction not working as expected

Java SDK
1

When there are multiple requests for updating the same document in a AttemptContext transaction block, data becomes inconsistent because of concurrent threads trying to update the document. Also getting a warning message

[com.couchbase.core][IllegalDocumentState] Tried committing document <document_id>, but found that it has been modified by another party in-between staging and committing. The application must ensure that non-transactional writes cannot happen at the same time as transactional writes on a document. The change will be committed with CAS=0, which will overwrite the other change. This document may need manual review to verify that no changes have been lost. Last document state=cas=<CAS>,seqno=<SEQ_NO>,vbucket

This leaves data inconsistent.

2

Hi @nks067
What is your use case for updating the same document concurrently in the same transaction? From a performance perspective it’s introducing unnecessary writes. And from a consistency perspective, it’s racing which of the two operations will succeed.

If you upgrade to the latest version of transactions (either Java transactions library 1.2.4, or we now recommend users use the version integrated into the SDK as of Java SDK 3.3.0), there have been improvements to the protection against this specific scenario of updating the same document concurrently. You will no longer get that IllegalDocumentState warning, because the transaction will no longer be allowed to proceed to the commit point if concurrent updates are detected.

I should stress that upgrading will not fix your issue. We see non-determistic concurrent updates to the same document in the same transaction as an application bug that needs to be resolved, and that it is better to alert the application that it has a race to fix, rather than try to proceed. The logic is, surely after a transaction, you want to be certain of the final state of all documents in that transaction?

So, if the updates happen to occur in serial then the latest version of the transaction code will merge them down into one update and the transaction will proceed. But if we detect that they are occuring concurrently then, for safety, we will fast-fail the transaction with an appropriate error message.