Instead of putting rollback into a try/catch you could also implement a Dispose method the calls rollback if the initial BeginTransaction has not been commited yet. So when the transaction goes out of scope without being commited, Roolback ist called automagically. If you'd want nested transactions you can implement a NumberOfOpenTransactions counter
The Transaction object will also call Rollback in its Dispose method. However, I don't like this implicit behavior and prefer to make it explicit with a try/catch block.
@@MilanJovanovicTech So if Rollback is already being executed in a Dispose method anyway, what's the use of having to call it implicitely? No offense, Milan, but IMHO the try/catch/Rollback are unneeded, even introduce redundant code, and therefore should be removed for the sake of simplicity and good readability. The using statement already tells the reader explicitely that unmanaged resources (in this case the transaction) are freed when the using block goes out of the scope
@@JoeMeyer8998 There was an issue you could run into if you don't rollback manually. I'm trying to find the documentation link I ran into for reference, but can't find it at the moment :(
Nicely put. I had an idea what transactions are used for and have only ever seen 1-2 implementations of them, but with debugging them in this video I understood them more.
Thanks Milan! The debugging part is really the cherry on top of an already delicious cake. You are very good at this, I'm proud I found this channel. Your content is gold mate, I'm having a lot of fun =)
I like al of your series, I'm in the industry almost for 8 years, I rarely seen people doing videos with good content. Very informative. Keep it up buddy.
Thanks Milan! My question is regarding "BeginTransaction()" method and it return type. You are telling at the end, that is possible to return a different type to expose less methods. Could you give a code example, because i did not understood this point. Thanks !!!
The DbContext stores a 'CurrentTransaction' instance internally. You can just wrap the calls to BeginTrasaction/CommitTransaction, and don't need to return the transaction instance.
Thanks Milan., But i don't see what the RollBack is actually for, since anyway as long as we haven't reached the transaction.Commit(), nothing is written in the database ? Could you please detail that point ?
For closing the transaction, and reverting any partial changes. For example, you could have a few SaveChanges calls in a single transaction. And those changes should be visible to queries in the same transaction.
Hi Milan, I have done your same thing with unit of work and injected dbcontext and other services that I use in my project, for dependency injection i have used autofac and registered dbcontext as InstanceForLifetimeScope so all injected services in my unit of work capture the same dbcontext, because every service inject dbcontext, all works if I do begintransaction the first time, but if I want to do again i get exception that dbcontext has already a transaction, shouldn't be disposed automatically with autofac or at least the transaction.commit() close the transaction, what if I want to get new transaction every request and not keeping the old? Thanks in advance. I hope i was clear.
I inject unit of work in form and I want to use every time that I press the save button, that can be pressed multiple times, but every time I need to create new transaction, if I do like you did the previous transaction is not disposed and I get the exception that the transaction has already been started, how can I fix that? Thanks in advance.
I have trouble in this bug "System.InvalidOperationException: 'A second operation was started on this context instance before a previous operation completed", I mean I just executed transaction for the first time but the second was not
There is a subtle problem with the implementation. The get gathering by id call is still a separate transaction (since every sql statement is treated as an implicit transaction, in case we dont specify explicitly) and in case of concurrent writes, it might lead to the invitation object becoming stale by the time we try to write to db. Obviously it will throw and the catch clause would ensure graceful exits but we can improve the number of failed writes by having the read call within the same transaction in which we are writing. Please let me know ur thoughts... also nice video.. cheers 😊😊
| Obviously it will throw Only if we have optimistic concurrency. The default isolation level is ReadUncommitted, which doesn't lock rows in a transaction - so that won't help with the first query.
Don't you think it would be a good idea to also have the read operations within the transaction? Having a more strict isolation level, the read rows would also be locked by the db to make the whole method atomic from the perspective of the db.
I've noticed, you're using EF's entities as your domain model. There is a kind of implicit dependency on EF because EF applies some constraints on how we should design our entities (additional constructors, setters, etc.). Is it practical to don't use EF's entities inside a domain model? Which way do you recommend?
I've done it like this many times before, and didn't have a problem. With EF's fluent configuration you can get around most issues with encapsulating a domain model. You can have two separate models, one for the domain and one for EF, but I find it cumbersome to have to maintain two models if I can get by with just one.
Very good tutorial👏🏻! I am still wondering how to handle the transaction when dealing with several different data repositories. How to pass a subset of the repositories selected in a given context and validate it at the end?
So now the real issue: How to commit it async? I am using TransactionScope which can wrap multiple DbContext instances on the same connection string but there is this issue - the async version of the commit call is not available.
@@MilanJovanovicTech Then is there a workaround you suggest e.g. with Task.Run()? Do you think it is a good idea? I am thinking of a server process doing these transactions, that might be a real bottleneck when it's blocking calls.
@@MilanJovanovicTech when You will enable transactionScopeAsyncFlowOption it will works, additionally if I will have for example 5 repositories instances (for example I will call methods from injected classes) I don't care about it, just all saveChanges taken to one Transaction. I'm just wondering if TransactionScope is more elastic solution. (Of course all depends :) but what do You think?)
it's not all, you didn't cover read committed, no need to have a couple of saves for that scenario, just do the validation for some uniqueness and make one save, call this logic concurrently and you'll be surprised =)
Great work. Thank you. One question I have on your code. After if (attendeeResult.IsSuccess) should you not put "else" and inside it to roll back the transaction ? I mean if it is all or nothing. Thank you.
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
A quick tips: if you use DbTransaction abstract class instead of IDbTransaction interface, you can use async methods.
Figured that out recently! But thanks for posting the comment. I'm sure it will help someone.
Instead of putting rollback into a try/catch you could also implement a Dispose method the calls rollback if the initial BeginTransaction has not been commited yet. So when the transaction goes out of scope without being commited, Roolback ist called automagically. If you'd want nested transactions you can implement a NumberOfOpenTransactions counter
can you give more insight on your saying.
The Transaction object will also call Rollback in its Dispose method. However, I don't like this implicit behavior and prefer to make it explicit with a try/catch block.
@@MilanJovanovicTech So if Rollback is already being executed in a Dispose method anyway, what's the use of having to call it implicitely? No offense, Milan, but IMHO the try/catch/Rollback are unneeded, even introduce redundant code, and therefore should be removed for the sake of simplicity and good readability. The using statement already tells the reader explicitely that unmanaged resources (in this case the transaction) are freed when the using block goes out of the scope
@@JoeMeyer8998 There was an issue you could run into if you don't rollback manually. I'm trying to find the documentation link I ran into for reference, but can't find it at the moment :(
public async Task BeginTransaction(Func action, IsolationLevel isolationLevel = IsolationLevel.ReadCommitted)
{
using (var transaction = _dbContext.Database.BeginTransaction(isolationLevel))
{
try
{
await action();
await transaction.CommitAsync();
}
catch (Exception)
{
transaction.Rollback();
throw;
}
}
}
Nicely put. I had an idea what transactions are used for and have only ever seen 1-2 implementations of them, but with debugging them in this video I understood them more.
Glad I helped you understand the concept better :)
Thanks Milan! The debugging part is really the cherry on top of an already delicious cake. You are very good at this, I'm proud I found this channel. Your content is gold mate, I'm having a lot of fun =)
Thank you, I'm happy to hear that
I Appreciate the bright screen warnings lol
I do too 😂
I like al of your series, I'm in the industry almost for 8 years, I rarely seen people doing videos with good content. Very informative. Keep it up buddy.
I'm humbled to hear that! 💌
Bright screen incoming 🤣🤣 Great video
I don't wanna hurt your eyes 😅
Rather than switching to "bright screen" SSMS you can also use the SQL Server tools built into visual studio to run queries and show data. :)
You have a good point there! Thing is, I never used it. So the idea didn't even cross my mind.
Great content. Very happy to have discovered your channel. Keep up the good work!
Welcome aboard! And you can expect more great things in the future 😁
Great job Milan. I'm not a big fan of EF. Please consider making a video about transactions with Dapper.
It's even simple with Dapper really, but sure thing 😁
Hi Milan can you please make a video on GLOBALIZATION & LOCALIZATION with shared resources in NET CORE 6
Alright, seems like people wanna see it 😁
+1 this will be great!
@@MilanJovanovicTech yes, Thanks s lot in advance. May Allah always bless you
@@MilanJovanovicTech in today's video reminding you about this 'Shared Culture'
@@zameer.vighio Okay, I see. I added this to my content list. But I can't promise when it'll be released. Won't be soon.
Great video Milan! Keep it up with the good work!
Thanks, will do!
Thank you! It would be great if you tell more about isolation levels in one of your next video!
I think it's something people rarely think about, and even fewer people understand. I'll consider it though!
Awesome video, way to go! Thanks for bright screen notification )😃
My pleasure 😊
Thanks Milan!
My question is regarding "BeginTransaction()" method and it return type.
You are telling at the end, that is possible to return a different type to expose less methods.
Could you give a code example, because i did not understood this point.
Thanks !!!
The DbContext stores a 'CurrentTransaction' instance internally. You can just wrap the calls to BeginTrasaction/CommitTransaction, and don't need to return the transaction instance.
great video!!
Thank you!!
If any of the savechanges fail, we would then go to rollback in the catch block?
Thanks for an amazing explanation as always!
Yes, that's how it works
Thanks Milan.,
But i don't see what the RollBack is actually for, since anyway as long as we haven't reached the transaction.Commit(), nothing is written in the database ?
Could you please detail that point ?
For closing the transaction, and reverting any partial changes. For example, you could have a few SaveChanges calls in a single transaction. And those changes should be visible to queries in the same transaction.
@@MilanJovanovicTech Thanks Milan, but how could those SaveChanges affect the Database whereas the transaction.Commit() has not been done ?
Thanks Milan...!
You're welcome :)
Thanks for a video. Very necessary Topic 🙌
Glad it was helpful!
Hi, Is it common to share transactions between different contexts? Or every context have your transaction life?
Each context (assuming it's a different type) will have it's own connection to the DB and thus a different transaction
Hi Milan, I have done your same thing with unit of work and injected dbcontext and other services that I use in my project, for dependency injection i have used autofac and registered dbcontext as InstanceForLifetimeScope so all injected services in my unit of work capture the same dbcontext, because every service inject dbcontext, all works if I do begintransaction the first time, but if I want to do again i get exception that dbcontext has already a transaction, shouldn't be disposed automatically with autofac or at least the transaction.commit() close the transaction, what if I want to get new transaction every request and not keeping the old? Thanks in advance. I hope i was clear.
You must've done something wrong, since the transaction should be disposed along with the DbContext
I inject unit of work in form and I want to use every time that I press the save button, that can be pressed multiple times, but every time I need to create new transaction, if I do like you did the previous transaction is not disposed and I get the exception that the transaction has already been started, how can I fix that? Thanks in advance.
It is the same for me..
I have trouble in this bug "System.InvalidOperationException: 'A second operation was started on this context instance before a previous operation completed", I mean I just executed transaction for the first time but the second was not
You have to commit or rollback a transaction before creating a new one
Great video! Based on what you demonstrated do you need to use rollback if the update won’t execute without the commit being triggered?
If the commit isn't triggered, then it's like there were no changes applied to the database. So there's nothing to rollback.
@@MilanJovanovicTech so then what is the purpose of rollback transaction 🤔
There is a subtle problem with the implementation. The get gathering by id call is still a separate transaction (since every sql statement is treated as an implicit transaction, in case we dont specify explicitly) and in case of concurrent writes, it might lead to the invitation object becoming stale by the time we try to write to db. Obviously it will throw and the catch clause would ensure graceful exits but we can improve the number of failed writes by having the read call within the same transaction in which we are writing. Please let me know ur thoughts... also nice video.. cheers 😊😊
| Obviously it will throw
Only if we have optimistic concurrency.
The default isolation level is ReadUncommitted, which doesn't lock rows in a transaction - so that won't help with the first query.
@@MilanJovanovicTech no, the default isolation level for postgres is ReadCommitted which uses exclusive locks during writes
Don't you think it would be a good idea to also have the read operations within the transaction? Having a more strict isolation level, the read rows would also be locked by the db to make the whole method atomic from the perspective of the db.
Sure, if we set the isolation level so some of the more restrictive values
I've noticed, you're using EF's entities as your domain model. There is a kind of implicit dependency on EF because EF applies some constraints on how we should design our entities (additional constructors, setters, etc.). Is it practical to don't use EF's entities inside a domain model? Which way do you recommend?
I've done it like this many times before, and didn't have a problem. With EF's fluent configuration you can get around most issues with encapsulating a domain model. You can have two separate models, one for the domain and one for EF, but I find it cumbersome to have to maintain two models if I can get by with just one.
Thanks Milan.. Do you have any DDD course with Dapper?
I don't at the moment
Very good tutorial👏🏻! I am still wondering how to handle the transaction when dealing with several different data repositories. How to pass a subset of the repositories selected in a given context and validate it at the end?
If they all share the same DbContext, they will also share the transaction
@@MilanJovanovicTech I was thinking of the case when repositories have different databases and therefore different contexts.
@@MrEkwador You can't - without a distributed transaction
Thank you, very informative 👍
Glad it was helpful!
Is it safe to use this Transaction in every process that is related to database?
It's unnecessary for simple changes. But yes, it's safe.
What happens if the catch block with the Rollback() call doesn't exist and an exception is thrown?
The transaction should roll itself back when it's disposed, but I like to make things explicit
@@MilanJovanovicTech Thanks!
So now the real issue:
How to commit it async?
I am using TransactionScope which can wrap multiple DbContext instances on the same connection string but there is this issue - the async version of the commit call is not available.
You can't, it doesn't have an async API
@@MilanJovanovicTech Then is there a workaround you suggest e.g. with Task.Run()? Do you think it is a good idea? I am thinking of a server process doing these transactions, that might be a real bottleneck when it's blocking calls.
@@MilanJovanovicTech I am surprised to have found DbTransaction.CommitAsync on microsoft online documentation :D
@@S3Kglitches Only for EF Core's transaction as far as I'm aware 🤔
Milan, how to handle deadlock situation due to transaction block
Where do you expect a deadlock?
Hello excellent video, out of curiosity you have the link to github, greetings from Colombia.
github.com/m-jovanovic
Thank you very much, I am doing a course and your tutorials are my lifeline.
I have a problem with this, rolling back is not working and changes are not reverted. not sure what's the reason
How can it not work?
Is it not better to use transaction Scope?
It doesn't support async operations - but otherwise, works fine. Note however that the transaction isn't committed until TransactionScope is dispoed
@@MilanJovanovicTech when You will enable transactionScopeAsyncFlowOption it will works, additionally if I will have for example 5 repositories instances (for example I will call methods from injected classes) I don't care about it, just all saveChanges taken to one Transaction. I'm just wondering if TransactionScope is more elastic solution. (Of course all depends :) but what do You think?)
CAN YOU SHARE YOUR GATHERLY GITHUB REPOSITORY need a project structure please
It's available on my Patreon
@@MilanJovanovicTech any other resource without paying money
it was useful :)
Glad to hear that!
it's not all, you didn't cover read committed, no need to have a couple of saves for that scenario, just do the validation for some uniqueness and make one save, call this logic concurrently and you'll be surprised =)
Maybe in another video
@@MilanJovanovicTech I have just struggled with this whole night, transaction scope with serializable isolation level helped
your code Theme color is attractive please tel me the name
VS dark theme + ReSharper syntax highlighting
Great work. Thank you.
One question I have on your code. After if (attendeeResult.IsSuccess) should you not put "else" and inside it to roll back the transaction ? I mean if it is all or nothing.
Thank you.
It'll be rolled back when disposed