20 facts about Cosmos DB Server-side programming model you should know

Posted by
  1. A server-side JavaScript function works with a context object. The context exposes a collection, a request, and a response
  2. Stored procedures and triggers are always executed on the primary replica of an Azure Cosmos container, though JavaScript runtime is installed on all the replicas.
  3. Queries using user-defined functions can be executed on the primary or any secondary replica.
  4. No matter what consistency level you have configured, using server-side programming model always guarantees strong consistency.
  5. The stored procedure runs under the transaction scope of a logical partition key. That means no cross-partition query is possible during a transaction.
  6. The server-side programming model guarantees ACID for all operations that are part of a single stored procedure.
  7. Transaction scope spans trigger, UDF and Stored procedure.
  8. Cosmos DB takes a snapshot of the document versions (ETags) at the start of the transaction. If code completes without any error, all the operations within the transaction are committed to the database and the temporary snapshot is discarded.
  9. Stored procedures and triggers are intended to support transactional writes. Cosmos DB SDKs or REST APIs should be used for queries.
  10. Stored procedures will ALWAYS read their owns writes.
  11. Last Write Wins is the default conflict resolution policy.
  12. Default conflict resolution policy uses _ts property in the document for the following APIs: SQL, MongoDB, Cassandra, Gremlin, and Table.
  13. If you are using SQL API you can specify any numeric property in your document as conflict resolver property.
  14. The system provides an exactly-once guarantee for the execution of a merge procedure as part of the commitment protocol.
  15. If you configure your container with the custom resolution option, and you fail to register a merge procedure on the container or the merge procedure throws an exception at runtime, the conflicts are written to the conflicts feed. Your application then needs to manually resolve the conflicts in the conflicts feed.
  16. Custom conflict resolution policy is only available for SQL API.
  17. Stored procedures, triggers, and UDFs must complete execution within a time limit, otherwise, the transaction is rolled back.
  18. Since scripts execute in a server-side environment, they are strictly governed. Scripts that repeatedly violate execution boundaries may be marked inactive and can’t be executed.
  19. Cosmos DB’s predecessor Document DB heavily relied on ChakraCore. ChakraCore is the core part of Chakra, the high-performance JavaScript engine that powers Microsoft Edge and Windows applications written in HTML/CSS/JS. Microsoft recently announced Edge moving to Chromium engine, ChakraCore development still continues for various non-Edge uses, and Cosmos DB is one of them. However, there is a big chance that Cosmos DB moves away from the ChakraCore. https://twitter.com/bterlson/status/1070754781822574592 https://github.com/Microsoft/ChakraCore/issues/5865
  20. Scripts consume additional throughput in addition to the throughput spent executing database operations.

For more detailed documentation check https://docs.microsoft.com/en-us/azure/cosmos-db/