Forum Discussion

nitinrahim's avatar
nitinrahim
Brass Contributor
Jan 02, 2024

Replace Operation Cosmos Db

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 er...
mannu2050's avatar
mannu2050
Icon for Microsoft rankMicrosoft
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. 

    • nitinrahim's avatar
      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

      • mannu2050's avatar
        mannu2050
        Icon for Microsoft rankMicrosoft
        Jan 04, 2024

        449 error generated when you do multiple operations on the same document at the same second. This happens during load test when there is a skewness of sample values and you end up concentrating all of load to specific values. It can come up with any of the methods you have mentioned. 

  • nitinrahim's avatar
    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's avatar
      mannu2050
      Icon for Microsoft rankMicrosoft
      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

       

      • nitinrahim's avatar
        nitinrahim
        Brass Contributor
        Jan 03, 2024

        Thanks Manish. 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

Resources