Java Transaction API (JTA) transactions with concurrency

- [Teacher] Now that we've seen the four concurrency Enterprise Services, let us talk about how concurrency deals with the transaction management. Now we all know this Java Transaction API that we already have. We have even talked about it in an earlier part of the course, but let's quickly revise. It's a list of interfaces that are provided between the transaction manager and the transaction management components, like your application servers, or your application code or your resource managers. And there are many kinds of transactions that you can make. Let's look at few scenarios: I have a situation where there's one data source, which is connected to a single database. And then I have multiple data sources connected to the same database. And then, I have multiple data sources connected to two different databases and that too over a network. Which means, I have a situation where it is a distributed network, and I may have to perform transactions over each of the machines in the network. Now, when it is a distributed network, there will be global transactions. There may be transactions due to threads, JMS queues, application servers, etc. When we talk about concurrency programming with JTA, it is definitely going to become a little more complicated. If you have a distributed environment, then the most basic operations like commit, rollback along with concurrent processing can be really a challenge. In order to guarantee that commit and rollback operations successfully work and the data integrity is mentioned, that has definitely to be handled carefully. So when it comes to concurrency programming, it completely depends on the Java Transaction API to make sure that these commit and rollback operations work successfully. We have this user transaction javax.transaction.UserTransaction API, which is something that your concurrency programming will rely on. It helps developers to demarcate those transaction boundaries. So I may have the transaction which is spread among different threads, CPU cores, machines, or even networks. But the user transaction API that I have with me will ensure that all of these transactions operating in a single unit will be managed correctly. So when I say managed correctly, there will be a commit when we are very sure that all of the units transacting within that single transactions are ready to commit. Otherwise, if there is anything going wrong in any of the bits in that transaction, the entire data from the database will be rolled back, and the database will be restored to the previous state. So that's what this means. And of course, we talked about a term previously, which spoke about global transactions, and XA extended architecture resources. And we said that your database driver jars should definitely have the XA resource available, which can help you make sure that this global transaction and distributed transaction process works well. My SQL database server that we have chosen and the driver jar corresponding to that the dependency that we added in the project, definitely has XA global resource so we need not worry about it. So if you want to try out concurrency programming across a distributed network with the user transaction API of Java transaction management, then yes, you will be able to do it without any problem. So just to make sure we are clear on what we're doing, let's say if you have a thread which is now performing a lot of transactions together, look at this code that I'm showing on the slide right now. You have this usertransaction.begin, which is starting the boundary of the transaction. And there after inside it, you can have many calls, you can call an easy business method, you can call a restful web service, you can make a database call and all of these sources may be placed across the network. But once all of them finished their jobs, then we are going to say commit and user transaction object is going to take care that it commits only if all those operations are definitely successful. Otherwise, it will help us roll back the entire data and we will be safe. Now, whenever in a restful web application you want to get hold of the Java transaction object, the user transaction, yes it can be very easily obtained using JNDI lookup. We have done JNDI lookup before in all of our demos and we know how it is done. There are two ways you either do a JNDI lookup or you inject it using the resource annotation. But this object explicitly we're going to have wire the JNDI lookup in restful classes or whichever components that you want to inject into.