CasMismatchException Error show

[gelopi_ghost]

Couchbase\Exception\CasMismatchException

cas_mismatch (9): "unable to execute HTTP operation "query": ec=9 (cas_mismatch)", serverError=12009, "DML Error, possible causes include CAS mismatchFailed to perform UPDATE - cause: MCResponse status=KEY_EEXISTS, opcode=SET, opaque=317205, msg: " in 'http_execute'

This is my code, and I am using PHP SDK:
update Project.Dev.admin SET LastLogin = '2023-02-03 11:53:45' WHERE Id = '19'

Hi, I am getting this error, does anybody know how to fix this? Thank you.

[mreiche]

The error indicates that you’ve attempted to modify a document, but have not supplied the current (or any) CAS. I find that strange to see on a query. I thought it was only possible from the kv api.

Here’s the link to the php sdk that describes optimistic locking Data Operations | Couchbase Docs

[dh]

To effect the UPDATE, the Query service must first retrieve the original document then apply the desired changes and lastly attempt to write the changed document back to the data service. (If you EXPLAIN an UPDATE statement you can see the logic mapped out.) If multiple statements are attempting to update the same document at the same time, it is possible for them to all retrieve a copy of the document before any one manages to change it. Once one has changed it, the others will receive a CAS mismatch error when they attempt to write their changes.

This is the same as would be encountered by direct KV clients and is obviously timing dependent.

As noted in the optimistic locking documents linked to above, typically clients that tried to update but failed with a CAS mismatch need to establish if their operation is still valid, and if so repeat it. (https://docs.couchbase.com/php-sdk/current/howtos/concurrent-document-mutations.html#handling-cas-errors)

For example, if one client is only updating field A and another field B only, it would be safe/valid to repeat the update for whichever received the CAS mismatch. If they’re both updating the same field, then application logic must decide if the later changes are valid to overwrite the earlier ones.

HTH.