How can we improve Azure Cosmos DB?

Transaction support in client SDKs

it would be useful if documentdb transactions are supported in .net, rather than just storedprocs and triggers.
using trans = newtrans()
db.addsomething() //ok
db.addother() //fail
end try
end using

1,203 votes
Sign in
Sign in with: Microsoft
Signed in as (Sign out)
You have left! (?) (thinking…)
Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Microsoft
Signed in as (Sign out)
  • Robert Kuzelj commented  ·   ·  Flag as inappropriate

    Please reconsider your decision. MongoDBs showed its possible.
    Apart from the fact that Txs are only possible atm with stored procedures they are also only possible for the same collection. Both of which leads a lot of error prone infrastructure code that needs to be written in order to emulate cross collection Txs

  • Damian commented  ·   ·  Flag as inappropriate

    Hello I plan to implement some wrapper for document db on MIT license. Something similar to transaction scope based on SDK operation on db collection/collections that will be translated to stored procedure and executed so all operation will be executing in transaction.
    Question for Azure Cosmos DB Team. Is it good idea ? Are there any impediments to achieve it?

  • Josh commented  ·   ·  Flag as inappropriate

    I need to update multiple same-partition collections in a single transaction. Please implement this.

  • John Wyler commented  ·   ·  Flag as inappropriate

    Why is the team not implementing this feature? I’d rather write client side code and execute it on the server than write JS stored procs. We need transaction support in .NET.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Without transaction, what should you do to update multiple documents in a row? Stored procedure is not acceptable, it's not for modern application.

  • Anonymous commented  ·   ·  Flag as inappropriate

    An example use case not currently supported is to be able to edit/add documents in multiple partitions, but in an all or nothing transaction.

    start tran
    Insert document on partition 1
    Insert document on partition 2
    commit tran

    Even having a max time-to-live for an in process transaction would be ok.

  • Andrei Pacurariu commented  ·   ·  Flag as inappropriate

    Transaction isolation (like Snapshot for optimistic concurrency) notwithstanding the ability to have a client-side initiated Unit of Work is very important. Currently Document DB supports transactions for the purpose of affecting multiple documents in the same collection in a unit of work all or nothing fashion only via server-side stored procedures. I completely support the ability to initiate the same behavior from the client-side with the same level of isolation that Document DB stored procedures would offer! Basically, we need client-side initiated transactions for documents in the same collection.

  • Andrei Pacurariu commented  ·   ·  Flag as inappropriate

    It's great that we can have ACID transactions across multiple documents in the same collection via stored procedures and triggers but it would be even better if we could have the same behavior using client-side transactions such as TransactionScope. Having part of the logic running in JavaScript on the database makes it harder to maintain and subject to a unify unit testing and source control strategy, etc.

  • Sich commented  ·   ·  Flag as inappropriate

    I think implementing a provider for EF7 ( cover this case.
    Also I should note that ambient transaction does lock resources in the same way as explicit transaction unless you use non-locking levels of isolation like snapshot.
    I totally support you with the rest.

  • DocumentDB coder commented  ·   ·  Flag as inappropriate

    Absolutely agree.

    Unit of Work pattern is vital -
    Start some unit of work (or "Transaction") do a bunch of stuff, then commit everything to the server at once in a atomic transaction.

    I don't like server side programming for a number of reasons
    1) it's a different language so not great for skill reuse when all our devs know & use C#
    2) they're impossible to debug
    3) they're a pain to deploy to multiple collections
    4) they're a pain to keep in sync between prod & dev
    5) they're impossible to unit test

    and finally, and probably most importantly
    6) they force me to move application logic out of my application and on to the server which is just bad.

    Note, this doesn't have to "lock" resources like a Begin Transaction / Commit Transaction on SQL Server would do, it should just execute all the changes in an implict transaction just like executing a stored proc currently does.

    I want the same functionality without the pain of server-side programming

  • che commented  ·   ·  Flag as inappropriate

    After writing a few server-side scripts I agree that a .Net flavor would be much easier for me.

  • Mike commented  ·   ·  Flag as inappropriate

    Apparently you only support JavaScript. Many back-end programmers prefer .Net

Feedback and Knowledge Base