Spring Framework - Lesson 5 - @Transactional

hello again everyone thank you for joining me and for watching again also this vid on this is already the fifth lesson that we have on the spring fundamentals stream and of course before starting I would like to advise you to share the channel with others and to subscribe if you haven't done so yet and of course we will start together with transactional and we will discuss about transactions this is actually a very big subject so this is something that we will continue to do in the next lessons as well but it's also a good opportunity to not only start to discussions about transactions but also to recap a little bit on the JDBC connection that we've previously done and you will see that the transactional annotation is used by spring within an aspect that we have discussed in the last lesson so the last two lessons now will mix into this this third one where we begin the transactional in order to understand this lesson you first need to understand to the subjects we have discussed in the previous two lessons so let's begin first with a new project and we discussed directly on the code so my opinion is that that we can start today directly with creating a new maven project and we add the needy dependencies and afterwards we will create a new database actually I have here a local server started and I have my sequel workbench I will use my sequel as I have done also in the previous examples and I have a demo database already created but I don't have any table so I will create a table and then we will discuss about working with this table from our spring project so let's let's go back oh and by the way don't forget if you watch the event life then you also have the opportunity to ask questions I'm always with an eye on the live chat and if you have any questions on anything that we are working on and if you have questions maybe about something that I have already discussed and you want me to redo a specific example please tell me in the live chat and I will try to to answer your questions so to continue with the maven project I will simply create as usual a normal maven project and I will use the latest Java version that we have available that is version 12 now so we can simply use a group ID the reverse URL in this case I will simply use my name and it would be Spring Framework I think this would be an e5 that's from the lesson 5 so the fifth example and we can simply create directly the project and the first thing that we need to do or of course would be it with the needed dependencies so I'm here in the poem XML file and in the poem XML file that's empty for the moment as usual I have to use to add the dependencies tag and installation inside the dependencies tag I would you add each dependency that that I use so in our case from Spring Framework let's use the context dependency that we are used to already and I will simply choose the latest version so nothing special about about the version I as usual will always choose the latest one and beside the context then here if I attempt to use JDBC to work with my my sequel installation here I need to use the JDBC dependency as well and we will need to use the my sequel driver so that's my sequel and we need the connector and of course here as well I will simply select the latest version oops so my civil connector in the latest version and because we are discussing about transactional and transaction ability in spring we will need one more new dependency that is the TX dependency from spring so the fourth dependency that I add here is this dependency and I think this should be it for all the dependencies that we need for our example previously we have used I think also a P dependency but I don't need explicit tree now because I won't explicitly use a yo pill I have did in the previous lesson so the only dependence is that I need is the context one so I can manage the context and the JDBC one because I will work with JDBC template and I will try to connect to my database and I use this TX dependency so that I can use the transactional and all the related things that we will learn about today and of course we need the driver in order to connect to the database and I think it should be it so if we've managed to add our dependencies in pom.xml then we can straight directly go to the implementation and inside the Java folder we can then first of all at the main package in which I have the main class as I have always done so a new main class and then we have the main method and of course here is where I will need to declare my context in this case and here is where I will call the the metals from the beans to approve everything that I'm working on and that would be declared the context of our CE pneu as usual annotation config application context because we will use annotations and I have person 12 here but I didn't set up the version for my maven projects and I need at least the language level set to 10 in order to be able to use the volume word so I will do this now and then I should be able to use the VAR word as well and you know that the next thing to do is to configure our context and to add the needed bins and for that I will have to use a configuration class so next thing in order to be able to continue I have to create a configuration class that I will do as well as I have done until now in a separate package so let's create a different package here that we can call config for example so that's from configuration and inside we create the needed class that would be project config and as usual the configuration classes we know he is advocated with add configuration and let's see what do we need to declare in the end the project config loss of course will be used when we create the context so we can do this to be sure we don't forget it as usual I use the project config class to declare the context and then probably here I will take something out of the context at some point and the project config lass is my only configuration class of this project and as usual it is advocated with add configuration and let's see what bins do we need in this case and again we are working with database so we will need a data source so let's first make sure that in the context we create a beam of type data source that will be needed from the JDBC template as well as from our you will see transaction manager that we had as a noob in today and I need a method that returns data source I can call it data source and in order to be considered being creator then you know already that I have to add notate it with the at being add notation and inside the method I have to return that instance of being that I want to be placed in spring's context so that instance of object that we want spring to know about and to be able to manage and in this case as I've done also last time when I've shown you how to connect to a database from spring I will simply use the driver manager datasource does the simplest intent terms of configuration and we don't have to lose time to setup more than three parameters of this object that will be only the URL so we're database is the username and the password that will give us the needed privileges to connect to the database so it's easy we simply create an instance of type datasource if you don't like the name is very big so we use a version 12 here we would would be able to simplify the syntax by simply replacing this fifth bar and we know that in the datasource we need to set the URL and we need to set the username and we need to set the password so datasource set password and because I have the default installation here and nothing is changed I I can simply directly use route with no password I don't have any user configured in my DBMS here it is only a plain default installation of my sequel with root and no password that has all the needed privileges and of course I need to specify the path to the database that I want to use so that would be JDBC my sequel and localhost because I have it on the local machine and then I don't need to specify any port because I simply use the default one in my sequel which would be three three zero six but if it is the default one then yeah I can simply skip the Declaration of the port and I need the name of the database and coming back to the database I remind you that my database is called the demo so this is what I use and this is what I need to use as well in my url for the data source creation and of course at the end of everything we need to return this instance and again the instance that we have here created configured and then returned will be placed in the context of spring just because I have here placed at bean above my method so if you are not aware with this and you see this video the first time now by the way this is actually the fifth lesson of the supreme fundamentals course and you will find the first four lessons on the same channel so if you are not aware already of what at beanies or at configuration or things that I have done already without explaining them they are already explained in the first four lessons so if you don't know them already you can or any time go back and and review the first videos and then come to this one so you need that we noticed there we need these data source in order to create the JDBC template and the next thing yes that we need to create the JDBC template that will help us to work very easy with database to send queries and to execute queries in a fashion in which we eliminate all the boilerplate code and yes let's create a new instance of JDBC template and then we need to specify the data source here and you know that we can simply call the data source method from above or if this looks strange to you because it looks like we always create a new instance this is not true I have explained this in a previous video but if you don't like this way of injecting from one method to the other to wire the beans directly through the metal calling then you know that you can also use as a parameter here data source and you simply use the parameter than further and even if I didn't write any Auto wired here by default this bin this parameter value here will come from the context of spring so spring at the moment of the initialization will know to inject this this instance and will know to take that one that we have already declared above and the third thing that we need in this example and this is something new this is something that we haven't seen before in this spring fundamentals course stream is a transaction manager and the transaction manager will be needed as the object that manages the transaction ability in our project so in the last lessons when we have created that I created an application that connects to a database we have only used the JDBC template and we have used no transaction ability and because of that here you will see our use cases warrant atomic and we miss we are missing the privileges of using transaction manager but this is what we will do and this is what we learn new and actually start to learn in this lesson it is quite a big subject so that we will need more lessons to cover all the fundamentals of it but the first thing to be done is to have actually this kind of object in our context and this kind of object in spring is represented by the interface by the contractor named platform transaction manager so this is why here I will actually return a platform transaction manager and platform transaction manager is that interface that contract that needs to be implemented by any object that's implementing a transaction manager in spring so you can use and like here we will use a predefined implementation of transaction manager but you can anytime create your own transaction manager and if you want to do so you need to implement this contract this is the contract that will be understood by Spring Framework as being the transaction manager so let's call this transaction manager and here as well as for the JDBC template because I will use a data source transaction manager I will wrap in the transaction manager to data source and I have to take the same data source the one that I have declared in the context so I simply injected the data source as a parameter here of the method and the method for the returning the platform transaction manager is as well a beam so we want this object to be placed in the spring context so it can be managed by spring and the name of the implementation that we will use here is [Music] maybe you can see only TM to be shorter is the data source transaction manager and this needs parameter the data source so actually I don't I don't need the Declaration of the local variable because I don't do anything with this I can simply return it and this is the easiest way to so now what we have in our context is a beam that represents the data source a beam that represents the JDBC template we will use to interact with the database and the beam that will manage our transactions the so-called transaction manager represented in spring by the interface platform transaction manager so we will come into more details about this interface in the next lessons but if you want to take a little bit a look inside the interface you will see that if there are only three methods here and I want only to tell you about the the contracts that we need to know so the first contract that you need to know is the platform transaction manager and this is basically what we will use directly because you will need at least to provide an implementation of the transaction manager whenever you work whenever you need transaction ability in your project but you need to know also that the transaction status is also the so called the representation of the transaction if you want like this in in database so it's again a contract that will tell you what's about the current transaction in some situations you you need this or at least you need to implement this contract whenever you create a new implementation of the transaction manager or the transaction status so I will in the next lessons I will come with to into more details of some of some of these methods that you you will need to know but in order to understand them in my opinion you should first see an example you should first see an application of this and then after you see the application of this it would be easier to understand the contract so I will simply leave them now as a black box you don't need to know more about platform transaction manager for the moment just as this object is managing your transaction so this is why we have created this beam in the context and we use this predefined implementation that's called datasource transaction manager and that's actually managing our data source that we have provided again is one of the beans we have in the context and spring can manage it if this is fine if you don't have questions about this means that I have declared here until now we can go on further and we can declare our repository and our service and the repository is that class in which we will write the sequel queries and we will declare the operations directly down to the database and of course the services are those classes in which we implement the use cases so you will see that logically the use cases are generally needed to be transactional so the transactional the transaction ability we will declare it and we will see it usually in the service classes so here let's create a new package and this package will be repositories and in the repositories package I will create a new class that would be I need an object actually to work with so I don't have any table I have just realized now that I don't have any table in my database so in order to prove the functionality let's also create a table otherwise we don't we will not see anything so right-click and create a table and let's choose a very very simple object like product I think we have also used product in our third lesson when we discussed about connection to the database and this would be a very very small a very very simple table let's choose only two fields so for example we need an ID and the name and the ID would be my primary key not null I will simply leave it as an integer and I will only check also the auto increment so I will just let my sequel choose values for this ID and I will not provide them from my code and I have the name and let's let's suppose this is everything about our table so I only keep names of products name of the table is product the name of the primary key is ID it's of type int is auto incremented and I have another column that's called name that's type varchar which we will be actually represented as a string in my java classes and i apply and create this table and now i have this table in which if i select everything I would simply see that I have actually nothing yet so I don't have any product in my table so let's go back to our project where we were creating the repository and this in this case I will need to name it probably product repository and in the product repository in order to create an instance of this class inside Springs context I can go back to my project config class and use another method add notated with that bin but it seems that it might be easier in this case just to add notate the class itself with for example repository which is a stereotyped annotation and I have to be careful to go to my project config close and make sure that spring is searching in the repositories package and that is by adding the components con annotation and you we will simply declare here the array of packages that will be scanned so in my case inside the package called repositories I tell spring that I have stereotyped annotation that has to be parsed and spring at the startup of the application by default will parse this package will find out that this class is ADD notated with that repository and will create an instance of the bin inside springs context and again I will also need do the same with my services so I will create another package that I call services and inside the services I create let's call it a product service for our example and of course this would be also component so I need an instance inside Springs context and for that I can use the stereotype annotation at service but again be careful that this has to be as well declared in components come so if I now have two packages that have components repositories and services both of them have to be declared in components come so both of them have to be known by spring framework that they contain they possibly contain components and that is in this array I will also add my services package and now both of them will be scanned and the product repository and the product service classes will be found by spring and an instance of each will be created in Springs context and managed by spring so now that we know this is happening we can simply go back to the product repository where I will do the easiest thing ever I would just create a method that's called add product and let's say that here I simply received the name of the product because we made the table very very small and very simple so we don't focus on things that we don't care about and I would simply inject here the JDBC template using auto wire so I take from the context the bean that I have declared inside project config is this bin here that we have created just before when we have declared the project configuration so in the product repository we now inject we are able to inject this JDBC template by using auto wire and then we can simply write a very very short sequel query that is inserting a product that be inserted into product values now for the ID and the question mark does the parameter for the name and null for the ID just because the IDS anyway anyway Auto incremented this is the way we have declared it at the DBMS level and then we use JDBC template and we just state that we want to execute this query and the only parameter that we have is name and I think this should be it and you can see how easy and how how clean and how nice this JDBC template hides all the boiler boilerplate code and you don't see prepare statement statement connections whatever you would need if you would simply directly use the plain JDBC API from the standard edition and okay we have now the method that we needed to add a new product so we can go to the product service and here of course I would go own injecting the product repository and I do so by using Auto wired as well and then I would declare a method like add one product and let's consider this is our use case so what what do we actually want to do here is simply to call the add product and add a specific specific product so yeah you can you can give the name as a parameter or you can simply pass a name that you want is only an example so don't focus on that and further we can just go directly to the main class and in the main class we can take this product service and from the context get bin product service class so we can take it by type because we know you we have only one instance we we have the opportunity to directly take it by tie this way and then we call the add one product and let's run for the moment directly this this method and see what's happening so we will now for the first time run our application and see what's happening and after the execution that should probably and soon okay we can go to the database and we can recheck our products and of course inside we will have now inside the table just one line that represents the product that we have added from our application so if I run again this is the same application then I will add another product and each time I run the application then I will have one more product so when the run will be finished then you see that I have a second beer here so everything is now working exactly as we have in one of the previous lessons but what's what's new with that platform transaction manager that I have added so why did I need to add this platform transaction manager here because this was actually working also without this bin and we know this and we have seen this from the previous lesson so let's see what's happening in this case if for example inside my service I add throw of a new runtime exception and I will make it a sad face sad face here so I have simply thrown this exception just after I have added the product you can imagine that theoretically in inside business case inside the new skis that will you implement in a service you may possibly have and usually you will have multiple operations and the rule is that usually you would like those operations to be treated together as a group so you either execute all of them either you execute none of them so if you have any kind of exception during the execution of the use case you don't want the operations that have been already done to persist so this is atomicity for example if you have let's assume a very very simple easy to to understand situation in which you have two accounts and you take money from one account and put them into another account like a transfer money functionality and you take $100 from the first account and you put them in the second to the second account let's say that it succeeded to take $100 from the first account but then it failed before or at the moment of adding them to the second account then in this case if you consider the use case have been a success and you leave the first operation to be executed in the end the data would be are inconsistent because $100 would be missing they would they have been taken out from the first account but they are not in the second account and that means that you have lost $100 so you don't want this kind of his inconsistency and usually in a logical at at a logic level if you have exceptions and you don't treat the Nueske's as a transaction so in my case if the if adding the money to the second account would fail I want to add back those $100 to to the first account so I don't want neither the first operation to be done if the second one has failed either all of the operations are done correctly either none of them is executed this is most of the times what I want from a news case and this is one of the first things we will discuss about transactions the atomicity of the transaction so inside the transaction you either execute all the operations either execute none of them and this way you avoid logic inconsistencies of the data and in this case let's see what happens if I throw this runtime exception from my method which would be equivalent of having a problem during the execution of the use case so just to make sure that we know what we have in the database now so if I say again we see that in the database we have two beers and now I can go back in the mind into my main method and I run again this example and of course I should see an exception because it was thrown is my exception having the sadface here and then I go back to my database and when I go back to my database I actually see that even if I had an exception I still see that the third beer was added in the database and this is not fine at least not considering that the exception could have been a fact could have been affecting my data consistency what what I wanted actually to have is that if I if I have an exception that is thrown if one of the operations is not working inside my use case I don't want neither the others that have been executed to persist so I would have wanted in this case that the insertion of the third beer was not happening and for that I will have to actually do two more changes to my code and first of all would be in the project config last when you want to enable transaction functionality you have to add another add notation on the configuration class that's called enable transaction management so first of all now if we want to wrap into a transaction this use key is that we have first thing that we need to do is make sure that Spring has this transaction ability functionality enabled and you can enable the transaction management by placing above the configuration class D add an able transaction management annotation now you have to specify which is your use case so what method should be wrapped in a transaction so of course in our case is all about this method that we want to wrap in a transaction so what what I will simply do is above the method I will use the transactional add notation and by placing this transaction add notation above the method I will wrap the method in a transaction so the platform transaction manager been that you know we have added in the beginning in the context of spring will manage the execution of this method and if there is any exception thrown out of the method at execution then the transaction will be automatically rollback and that means that even if I have executed the ad of the product beer if before the end of the method I have any problem like any exception that is thrown then the adding the insert of the product will be rolled back and I will actually see that nothing will be persisting from the beginning of the transaction that in our case is happening to be the same with the beginning of the method this is something that we will discuss is not this case all the times but for the moment just imagine like is in this example is also true that when you have placed here transactional this method is now completely wrapped in a transaction and that means that a transaction is actually started before the execution of the method and the transaction will commit at the end of the method if something happens between the the start and the end of the transaction you will actually see that the transaction is automatically rolled back in fact the transaction is marked for rollback and when it comes to be finished it will actually be rolled back and all the operations that were previously done will be will not be persisted as it happens when we don't have a transaction technically how is it happening this is something that you also know from the previous lessons in actually the last lesson the lesson for that we have discussed you understood what an aspect is and more things about the AOP and if you remember we have discussed about all the join points we've started with at before after before returning so sorry after returning and after throwing and around and you know that for example with the around a drain point you can specify a point cut that is a group of methods to be managed by aspect and you can do something before after instead of the execution of the preceding joint point and in the example that we have done together we in the last in the last lesson we have simply directly specified the name of the method to be easier to understand but I've told you that there are a lot of sin taxes and you have the opportunity to specify a lot of precision like even you can even specify from where and from what package you want this aspect to affect the methods and so on in this case is much easier you actually have the transaction log notation so what you can imagine is that behind all this functionality you actually have an aspect that is wrapping around the methods that are ad notated with the ad transactional ad notation so this is the the point cut that the drainer the aspect applies to in this case are those methods that are ad notated with a transactional which is half true because you will see that transactional can also be placed above the class so during the lessons I will get into more details and you you will understand more but starting from the beginning you can simply think for the moment that is the methods that that are annotating are tied with a transactional they are intercepted by this aspect and they are this way managed by the platform transaction manager being that we have added in the beginning so now if my explanation was fine and if you understood you should know what is the purpose of the platform transaction manager the fact that in order to activate to enable the transaction ability you have to add this enable transaction management about the confusion about the configuration class and you should be aware of the existence of this set transaction a notation that we use above the methods that we want to be wrapped in a transaction so this and by these changes now we should have a transaction at least for the add one product use case that we have created in our service so let's see what happens if I run again after all these changes my method so let's let's run it again and see the exception that that is thrown so I've seen I've seen the exception as well and we can go back to our database and when you select you will actually see that there is no more the the bill was no longer added so you don't have the fourth product here and the reason for that and why why is this different from the last execution is that now by this transaction and by the fact that we have enabled the transaction ability the platform transaction manager created the transaction and when this exception has been thrown this was actually what triggered the Platinum transaction manager to rollback our transaction and the insertion of the beer product here now was was rolled back as well and was not done as as it happened in in the previous execution now if you take out the exception so now if everything is fine and you don't have any longer an exception you can run it again and we should see that the fourth beer is added to our database so I don't have any exception anymore and the process has finished and if i refresh now I see that I have another beer you know I don't mind the ID the ID is five because the fourth one existed at some point but it was the rollback yeah and this is how it happens not because of spring but because of my sequel and it's not our object of discussion here but now you see that we have a fourth product here and this this new beer was added in this case and the reason for that is because we didn't have any exception and more an exception so the purpose for having or at least one of them and the the first one that we discussed now of having a transaction is that you either want all the operations inside the use case to execute either if at least one of them failed and you had a problem you want to roll back everything so you don't get into logical inconsistencies in the data and you've seen how we've done that by using the transactional and in order to add this functionality to our project beside what we did already know from the third lesson we have only added the platform transaction manager being inside the context we have enabled the transaction ability by applying the enable transaction management add notation at the configuration class and we needed to specify which is the method that needs to be wrapped in a transaction by the new aspect that is created by placing above the at transactional annotation so this is what we have added above the functionality that we have already discussed in the third lesson related to connectivity to the database and this is what I want you to understand about from this from this lesson and what you have seen is only for my exit from my example because I didn't tell you which are all the theoretical things that you need to know you've seen that in order to make the transaction fail make the transaction rollback I have thrown an exception but I didn't tell you everything about this and of course there are a lot of things actually I didn't tell you about transaction that's why we will also discuss the same subject in the next class well the idea is that this doesn't happen for all the exceptions and there are some rules about exceptions that you need to know and the first rule that I want to tell you about this is actually that the default rollback of the transaction happens by default only for the runtime exceptions so in this case when I have added my throw of exception I I did add a runtime exception not only because I didn't want to do any more things with like throwing here the the exception itself the reason for why I threw a runtime exception is because this is the this kind of exceptions are actually the ones that cause by default or roll back to the transaction if I have used an exception like for example if I if I would have used a checked exception like simply exception can be exceptional any other checked exception doesn't matter then the problem would not have been only that I need to add the throws of the exception and of course even in the main method as well I need to do this and let me just for for simplicity at the throws here you will actually see that for these kind of exceptions by default the platform transaction manager doesn't roll back the transaction so if you run it like this where instead of having the runtime exception as I have done in the previous example I have added checked exception and you will actually see that I have here an exception and if I go back you know still even if I had an exception and maybe from my explanations you would have believed that this roll here would not appear anymore in our database because and only because it is a checked exception so not a runtime exception like it was in the previous example in this case the transaction by default will not be rolled back so there are a lot of rules that we need to discuss about transaction ability and all of these fundamental rules are very very important now that we are here I also want to show you something that that maybe we could have seen from the first example with the exception and that's the exception stack that's really really nice to observe just because you can actually see that by the transaction ability functionality is actually implemented by an aspect and you will see actually in the lines here that when we have run the method that's called at one product in our case and it is what we have done here in the main method you see that there is this method is not a directly cold and you you don't see directly the exception that is thrown on this line that would be line 17 here so you see a lot of lines in between this you see all the lines that are coming and you can see some words here like AOP and by that you you realize that actually this transaction interceptor is nothing more than a normal aspect the same kind of objects that we have discussed in the previous lesson and this is exactly why I want it and why why I meant discourse like this to discuss first the AOP and then the transactional so that you now understand how these transactional is really working where is this coming from where is the creation and where is the commit and the rollback of the transaction because you don't see them but you know that the reason for why you don't see them is because an an aspect is completely decoupled and we know this from the last lesson when we have completely decouple functionality that like the logging that we have done before and after the call of the method the same thing happens here with creating and committing or rolling back the transaction so the the reason for why we have first worked with JDBC and we have seen how to connect what database and we didn't discuss anything about transaction ability and then we discussed AOP and now if we we see the transactional and the way transactional works and you understand that you have now an aspect that that's wrapping around its weaving around these methods that you had not a twist transactional and from now on what you need to know is there are some rules there are kind a lot of rules even there if they are fundamentals there are a lot of fundamental rules that we will discuss about this transactional but the purpose for this lesson would be at least that you understand how is this transactional working that behind this transactional you have an aspect and how to enable this transaction ability and of course the first and the main reason of using a transaction that we have discussed and that is adding the atomicity to the operation of a Nueske's that we implement so that's basically things for the moment that I want I want you to remember and now there are a lot of rules that we'll discuss and in the first the first one I have shown you is that regarding the exceptions I told you that if you actually throw a checked exception you will not roll back the transaction but you will actually roll back a transaction in case of a runtime exception so this is also a rule that I want you to remember from the lesson of today that by default the transaction manager rolls back the runtime exceptions but does not roll back the checked exceptions and this is this is really really funny and well what is funny about this is actually this is the default but spring framework is a framework and as general any kind of framework is very very easy to customize and you can change all the defaults usually even like this default behavior so if you don't like the way spring is behaving by default like rolling back transaction for runtime exception but not rolling back the transaction for for checked exceptions you can simply go in the transactional annotation attributes where you can specify either the rollback for where you can say okay by default you transactional don't roll back for runtime exception but in my case I want you to do so so I can simply come here and specify I want steal even if it is a runtime exception I want spring to roll back for this exception sorry not roll back for it the other way around so not roll back for runtime exception because by default spring would roll back for any runtime exception so if I want to override if I want to change this default behavior I can say ok spring I don't want you to roll back for runtime exception and in this case for this method where I have applied this annotation with this specific behavior spring will work differently than at the end than the default it will not roll back for runtime exception or the other way around I can specify the roll back for and by default you have seen that for the checked exception like when I have specified exception itself as a class spring wasn't rolling back the transaction in this case but if I want override if I want to change this default behavior I can use the rollback for attribute and by this I would specify the opposite that when running this method I would want you to rollback for any checked exception so think I think that by default spring would undo but I can override these these default behaviors of the the transactional in spring and I can make the transactional rollback for checked exceptions and not rollback for runtime exceptions if I really want to do so usually you will use the default but if the reason you need to override them you have this possibility now the last thing that I really want to describe before ending the lesson of today is something that I know and I've seen is missing from a lot of examples and this is again regarding to the throwing of exceptions and something that that I I see poor explained in a lot of tutorials books articles and so on from different blogs is that it's only said whenever you throw a runtime exception by default the transaction the transaction manager will roll back your transaction but they don't build the fact that it has to be propagated outside of the method so by reading such an expression such a phrase that tells you whenever runtime exception is thrown spring would roll back the exception you could believe that if you have a try/catch for example let's have a try catch and tweet the runtime exception that we throw somehow doesn't matter how so the question is here is the transaction in this case is the transaction rollback or would I see a new bill in the database and the answer is in this case I will see a new bill in the database and the transaction will not be rolled back even if I throw a runtime exception and that's actually the mistake it's not actually mistaken but it's a poor explanation that I find in a lot of places is not only about throwing the exception inside the method but the exception has to be propagated outside of the method and the reason for that is because as I have explained you in this lesson is that aspect wrapping weaving around the method that is managing the transaction so if you catch the exception inside the method then the exception will never be seen by the aspect that's weaving around the method the aspect is somewhere around the method so in order for the aspect to see the exception you have to throw the exception out of the method so if the exception is catched inside and is never thrown out of the method the aspect would never see that that exception and will not will never roll back the transaction will treat it as normal transactions so it is not only about throwing an exception its throwing an exception and propagated to the aspect outside of the method that is how you should think about setting a transaction for for a rollback it's happening in the aspect when the aspect finds that an exception has been thrown and by default it has to be a runtime exception if you throw a checked exception the way we have seen in of the examples of today you have seen that also for checked exceptions by default you don't have this this behavior of rolling back and also you know that you can override this by using the a transactional annotation that we will cover again and from which we will cover a lot of more details in the next lessons so I don't want to go into more details for this lesson don't forget that you can ask questions in the live chat if you want through all of the live event and now I want to finish just by by telling you that more will come about transactional so first of all for today just make sure that we understand how to enable transaction ability and was the main purpose of adding a transaction to our use case and just the things about the exceptions that we have discussed and we will continue for the next lessons with propagation of the transaction and with as isolation of the transaction and we will discuss also about dirty reads phantom reads and repeatable reads and the issues that can come together with the isolation levels of the transaction and yes other than that I I can't tell you more for today just hope to see you soon for one of the next videos so see you soon bye bye

Channel: Laur Spilca

Views: 10,535

Keywords: spring framework, java spring, spring fundamentals

Id: HiiS0NVwnLg

Length: 59min 22sec (3562 seconds)

Published: Fri May 31 2019