Hi Team, We have noticed that during millisecond interval sequential operations (create, read, replace operations happening in very small interval) for some records even though we don't get an error we see the cosmos database didn't do a successful replace or update on the item. Is there a limitation in the replace operation with high volume requests with respect to atomicity? With Regards,Nitin Rahim

Sure, this is not a known issue hence support is a best way forward to debug.

nitinrahim you will definitely get a response if your request is reaching to database, Azure Cosmos DB is designed to have very high concurrency, it does billions of concurrent transactions. Basis your explanation it may be that during high concurrency the client app getting challenges, please refer https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/performance-tips-java-sdk-v4?tabs=api-async to follow best practices from client side. If it doesn't solve the issue then I will recommend you to raise a support ticket.

Hi Manish, We don't get an error response. We are not doing concurrent transactions for this test.We are doing sequential tests one after other immediately. However for the same set of transaction if we are using upsertitem we see 100% updates from the database side,however for same loadtest with same records we see few number of items not getting updated when using replaceitem method?And this is sporadic so its not related to data issue.Wanted to understand if there is the difference with respect to replaceitem method other than it replaces the entire document with the new document and upsertitem updates if document already exists and adds if document doesn't exist? We have a use case when were don't need to add the new document in case Id of the item doesn't exist that why we checked the replaceitem method? However we see these intermittent issues with replaceitem where even if there is no error ? Wanted to understand from backend side ( consistency level, internal replica quorum updates not getting reflected to server etc) why this difference in behavior with both of the methods( upsert vs replace) can be for the same loadtest? We are using single region write and multi region read configuration for this database. With Regards,Nitin Rahim

24 CreateItem will create a new item but will fail if there already is an item with the same ID. ReplaceItem will replace an existing item with the same ID but will fail if that item doesn't exists. UpsertItem combines the above two operations so it will either create or replace any item with the specified ID. Your use case much closer to UpsertItem instead of ReplaceItem. In any case you will get a response status for each operation, refer checkhttps://learn.microsoft.com/en-us/rest/api/cosmos-db/replace-a-document#status-codes Plz check if your application is capturing the response status correctly. You can investigate at the backend as well, one option is to enable log analytics to capture the correct state of each operation, refer https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs?tabs=azure-portal Another option could be to enable Time travel to validate the versions created due to update operations, refer https://learn.microsoft.com/en-us/azure/cosmos-db/synapse-link-time-travel?tabs=scala

Replace Operation Cosmos Db | Microsoft Community Hub

11 Replies

mannu2050
Microsoft
Jan 02, 2024
nitinrahim you will definitely get a response if your request is reaching to database, Azure Cosmos DB is designed to have very high concurrency, it does billions of concurrent transactions. Basis your explanation it may be that during high concurrency the client app getting challenges, please refer https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/performance-tips-java-sdk-v4?tabs=api-async to follow best practices from client side. If it doesn't solve the issue then I will recommend you to raise a support ticket.
- JillArmourMicrosoft
  Community Manager
  Jan 03, 2024
  mannu2050 Thank you!
  - nitinrahim
    Brass Contributor
    Jan 03, 2024
    Thanks Manish and Jill.
    
    We did notice we had response code 449 on certain replaceitem requests but on upsertItem we had 200 response for the same loadtest. Any specific reason why replace operation can encounter 449's with the same load while upsertitem won't and what does that imply?
    
    With Regards,
    Nitin Rahim
- nitinrahim
  Brass Contributor
  Jan 03, 2024
  Hi Manish,
  
  We don't get an error response. We are not doing concurrent transactions for this test.We are doing sequential tests one after other immediately. However for the same set of transaction if we are using upsertitem we see 100% updates from the database side,however for same loadtest with same records we see few number of items not getting updated when using replaceitem method?And this is sporadic so its not related to data issue.Wanted to understand if there is the difference with respect to replaceitem method other than it replaces the entire document with the new document and upsertitem updates if document already exists and adds if document doesn't exist? We have a use case when were don't need to add the new document in case Id of the item doesn't exist that why we checked the replaceitem method? However we see these intermittent issues with replaceitem where even if there is no error ? Wanted to understand from backend side ( consistency level, internal replica quorum updates not getting reflected to server etc) why this difference in behavior with both of the methods( upsert vs replace) can be for the same loadtest? We are using single region write and multi region read configuration for this database.
  
  With Regards,
  Nitin Rahim
  - mannu2050
    Microsoft
    Jan 03, 2024
    
    24
    
    CreateItem will create a new item but will fail if there already is an item with the same ID.
    
    ReplaceItem will replace an existing item with the same ID but will fail if that item doesn't exists.
    
    UpsertItem combines the above two operations so it will either create or replace any item with the specified ID.
    
    Your use case much closer to UpsertItem instead of ReplaceItem.
    
    In any case you will get a response status for each operation, refer checkhttps://learn.microsoft.com/en-us/rest/api/cosmos-db/replace-a-document#status-codes Plz check if your application is capturing the response status correctly.
    
    You can investigate at the backend as well, one option is to enable log analytics to capture the correct state of each operation, refer https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs?tabs=azure-portal
    
    Another option could be to enable Time travel to validate the versions created due to update operations, refer https://learn.microsoft.com/en-us/azure/cosmos-db/synapse-link-time-travel?tabs=scala

Forum Discussion

Replace Operation Cosmos Db

11 Replies

Resources