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()
This is currently not on our roadmap. However, we will continue to review this item in the future as we prioritize future releases.
Thank you for your suggestion and for the comments.
Michael Harris commented
Guess I'll use Mongo
first. use c#.
& find some db. cosmos dynamo spanner.
but only cosmos does not support transaction code with c#. irony
I'd LOVE to see this feature.
Dan Turco commented
while this not in the SDKs itself this has transaction support, and will soon be able to be commandline driven as well. #SelfPromoted https://github.com/d1820/cosmos-query-manager
Robert Kuzelj commented
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
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?
I need to update multiple same-partition collections in a single transaction. Please implement this.
I don't like stored procedures. Please make this feature happen!
John Wyler commented
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.
Without transaction, what should you do to update multiple documents in a row? Stored procedure is not acceptable, it's not for modern application.
Note that MongoDB just recently added this feature: https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
Any update on this?
Mads Krohn commented
Any news on this?
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.
Insert document on partition 1
Insert document on partition 2
Even having a max time-to-live for an in process transaction would be ok.
There is a duplicate idea asking for the same thing which is more popular so rather than duplicating it here with a few votes we should probably move our votes to the more visible idea - https://feedback.azure.com/forums/263030-documentdb/suggestions/16380400-allow-client-side-transactions-e-g-transactionsco
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.
I think implementing a provider for EF7 (https://feedback.azure.com/forums/263030-documentdb/suggestions/12505899-add-provider-for-entity-framework-7)would 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
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
After writing a few server-side scripts I agree that a .Net flavor would be much easier for me.