 This talk is named Narena Java Library for Transaction Processing. I am Andra Khalopka. I work from for Red Hat in particular in Narena team working with this library. Goal for this presentation is to provide some overview of the Narena capabilities to talk about the modules that Narena provides for the developers and I'll give you some idea how to use them. Just a brief one, because there are like several of them and expecting in case of interest, you will check the code yourself or to talk with us with developers on the forums. At the start, I will talk about some basic terms to understand the context that I will be using. So transaction is a unit of work. It's something that could be split to several steps, but we assume that all those steps will be done as one unit and this is what the transaction manager or library make working that it makes, that manages the transaction transactions and every steps inside of the transaction to be taken as a single unit. The third term, which I will mention is transaction model. Model maybe it's not precisely technical correct, but it's something that's a reason why you would like to use the transaction manager. It's a way that the processing guarantees what will happen when you access your data in the unit of work, which is kind as a transaction. So and with all of this, we have here the transaction manager, the implementation, which manages the transactions. And that's a Narana library, which consists of several modules with different approaches of the transaction processing. And here, the Narana is integrated with several application runtimes to be easy to use it and you can check it. Now I will go through the journey of World of Narana, how I named it as I am a fan of the RPGs, so the pen and paper in particular, I will take with me these guys on the journey. Hopefully they will give you some nice context of how the transaction processing works. Don't worry, I will be quite a lot talking about the code, but there will be some help with them to show what I'm talking later. So here is like some head of the band, the transaction manager, which manages some services, some tasks that compounds the transaction. The thieves uses his tools for finishing his works, various works is different, and that's why I need some tools. And all of that needs to be cooperated for the outcome, would be correct. So and yeah, let's say that these guys have a work, to steal a gem from a dragon, and here is the point, they need to somehow cooperate to finish their work. There is, as in other worlds, we have some rules that pays in that world. In other fantasy worlds, we can find the magic or dragons. Here we have these four guarantees that we know, that's the transaction processing guarantees for us. I will go through them quickly, just to for you to understand what is these capabilities for the transaction manager provides if you would the nirvana, it would be good for when you are using So first is atomicity or in other terms, it's nameless abortability. It's a way how to get back to the starting point, when at the starting point, when I take this example of the stealing a gem, so that if the dragon reveals the thief, then he has a chance to load his kind of game back and return back at the top of the start and tries his task once again. This is what atomicity says. And we have consistency, that meaning gem can be placed in several places at once or multiplied and just, it's once there that hidden under the dragon's body. So then it's isolation makes a guarantee that if multiple parties tries to steal the gem, there will be just once we will win and we'll get it. And with the durability, we know that everything will be durable after the action finishes. For example, even if the thief would die after it, still the gem will be out of possession of the dragon. Yeah, and these are the world, the all the transaction modules that Narvana provides and that I will briefly talk about. I will start about JTS transactions. If you don't mind, sorry, I will just check how is if there isn't anything bad with my, yeah, that seems that everything's hopefully working. So JTS transaction is kind of the old concept, but it's still a good base for the transaction processing. It is a standard, it comes from the IOP messages and in an orp world where the services talks with over the net and work as objects, RPC calls objects, remove RPC calls from service to service. On top of that, orp processing is created standard for transaction processing and which is OTS and on top of that is JTS, which is a standard how to bound these processing to Java. This is as well integrated then later with Java EE standards and available in application service. For example, in Wildfly. When I take an example here, I will, with this I would like just to show them a little bit code to where you can see what I'm showing this. There is this kind of the picture where you can see that there is different services, different processes, different JVMs or different processing, different machines. Each of them is orp service communicating over the net with the wireless messages. The main point is naming service where the services may be connected transaction manager or the service of business work and then the service does some work and it's managed by transaction manager to finish in the transaction manager. If I am now showing you a code that here is the service, this thief service, which needs for first some initialization of the orp properties, you need to know where is the naming server, set some setup, this is again, this is not about to show you how the things exactly should be done, just I would like to show you some feeling about what needs to be done or how this code working at that particular model works. And here in the comment method is the processing where we are getting the control to have some link to the transaction manager. We have resources that here I have just hand coded directly here to print something to the console log, but there could be anything like a database connection or something else. And these two services are then registered as a resource to the transaction manager and terminate it at the end of all work is done by committing and the termination service transaction manager finishes all the work in the transactional manner over those resources. When each service may call the other service and propagate transaction context from one service to the other to the other and then consider it as work as a unit of work that compound the whole transaction as single unit of work, then for more space that needs to be defined this EDL interface which is then transactional transferred to the Java interface. So this way then automatically the transaction context could be propagated from service to service, something that you would need to work with. It's like all the ways kind of, but I would just mention that this EDL stuff is like normal in current days as well even. So to summarize the GTS is like an ARP transactional framework in at least from the perspective of the Nairana implementation uses IOP messages to accommodate where the services communicates over that with each other. This, that code that I showed you that was like a little bit deep dive to the ARP and GTS processing. If you would be using integrate when this is integrated with application service, for example as EJB remote calls then these, any of these registration and stuff is done like in the background by application server that even that's quite like capable. This is like kind of considerate of all ways because working with IOP and all these stuff is not easy in all aspects. The next model that I will mention is JTA transactions, which is in fact its API on top of the, for Java to work with the transaction. It works with XA resources based on the standard two phase commit is used to manage the participants. All that is well integrated to many runtimes and transparently used by developers even they would know that there is in the background and any of these standards or APIs. And the thing that I will be showing here is here are my application runtime in my case Corkus integrated with the CDI where component accesses some database. So I will take, here is the method which is annotated with the transactional which makes from this in the background the application runtimes maintains the transaction for me that's it started or taken from some other call. And then because of it, I can work with the database here I am using ORM or JPA entity persisting it. And at the end of the method the transaction is committed. This is the integration with CDI. I can touch directly the JPA API with some calls. For example, here I have two calls just to show you where I can register synchronization which is some callbacks which will be called at the time when transaction is finished. This could be as well done with the CDI annotations but as I wanted to just like tell you about or show you there are some APIs that could be used directly this is one of them. Or I can say that some resource should be directly enlisted to the transaction processing. This call will be done for me by application runtime for the database resource. Here I have kind of the just handwritten XA resource again that is then used as via is used by transaction manager to inform about the end of the transaction. So, but from the perspective of a standard user this is just about a few annotations and all that's done transparently. So in GTA transaction there's some API which is based on XA transaction and two phase commit protocol to finish the transaction is transparent to most of the developers and because of that they were used well integrated. Next point is a software transaction memory which is like a little bit different from what I was talking about until now because until now I was showing some data sources to be work with the database, these persisting some stuff. Here is about the memory synchronization of a shared resource. When I have here the 3D is trying to get the lock picking tools I would be understanding them. Now as a threat which are trying to get one shared resource. For example, if I would have here these variables X, Y, Z then I can synchronize them if they will be accessed by three threats in parallel. That's fine, it will be working just maybe it could not be fully optimal invited. Sorry. That not all those three threats would be attaching all the shared resources maybe. There could be when running just the first and second threat very fine to leave them working in parallel without synchronizing them because they are using the Z just for the reading. With that, we can apply kind of the software transaction memory atomic block which would be not pessimistically locking those shared resources but like tracking what's happening with them and just just take the action when the mutual exclusion on that particle resources really needed. So this is what this idea with the transaction memory where the threat would be taking into, will be storing information about what are the shared resources that they are using in which way is that used and if that's accessed from other threat they can compare if there is really interleave between them and then take an action. This is the kind of the optimistic locking instead of pessimistic locking as synchronized block does here is reacting after that interleave happens. For this being possible, there is a handle not direct access to the memory. This handle is kind of that proxy which works with the properties and we are not touching directly the memory and for Narena, there is this approach. Yeah, we have the Narena provides again the annotation that I can say what is this shared property that's action number and say for the method what is the lock or what is the property that should be guaranteed on calling that method. Then as said, I can't directly access the property directly the action number. So I need some proxy. This is what I need to do to create the proxy and then in the resource I am getting the proxy and doing the action with the data in hand and if there will be some more parallel execution then the processing also for transaction memory guarantees me that there will be a set and an atomic. So the software transaction memory is like optimistic locking approach to for the VM in running processing to mutual mutual exclusion or the shared resource. Now, long running actions. This is like the approach for for using transaction in distributed systems. It's about like to create a microservice design where microservices talks to each other via HTTP calls and this the LRA is specification or proposal for micro profile that where it's integrated with Jux and processes the transaction handling in a little bit different way than until now that we were talking about set transactions but here we use the saga pattern which is which means that some of the responsibility for finishing of transaction is put to the service itself. But on the other hand, we are gaining the loosely coupling of the processing because until now that we were talking about asset transaction there is a data access usually requires some logs and that data sources which may cause the some slowing down the other services which are processing to the same data source. What this means is that transaction manager is not managing directly the data sources but the service creates the callbacks for compete or compensate which are guaranteed to be called at the end of the transaction. So again here our party talk to get to cooperate on some action transaction manager is trying to say when the action should is successful or not and call back to the services in the code. In the code again, this is about the annotations similar to what we've seen in transactional annotation for GTA, for LRA. It is the LRA annotation when ensures then when the endpoint, the rest endpoint is called then this service is registered to the transaction manager and it's start to be part of this unit of work. After this business processes successfully proceeded and if all other participants in that LRA is successful the transaction manager then calls back to the defined endpoints either compete or compensate in case of failure and it's up to the service to say what we'll do with that completion callback and that's the responsibility of the LRA transaction manager or LRA coordinators just to ensuring the callbacks are called and that it's called until the successful agreed on that the callbacks was proceeded on the service side. So now the summary is that these are the annotations used for the rest base processing that is used the saga pattern for that and this business logic is more more responsibility for closing or for managing for finishing the transaction itself and the services communicates over HTTP. I would highly recommend you if you are interested in this I would highly recommend you session that will be on Saturday. It's named different flavors of the distributed transaction and my colleague Martin Stefanko will talk about all the details about the microservices and transactions and distributed systems and saga pattern and et cetera and you will see how to easily code with that. For me now I have just two more modules to talk about here's the XTS and then REST-AT for XTS this is a module that is that is like kind of the using what we've already seen just in the in the area of web of the sole base web services. So there is that's based on the standards standards of WS-AT and WS-BA where WS-AT consists of the atomic transactions where all the assets all the assets stuff is guaranteed. The nice thing here is that you can bridge the JTA transactions with this web method calls over the different services and then this business activity part is based on the saga processing that's kind of similar that we've just talked now about LRA but again just based on the sole base web services. I need to find out the right place. This is the code of the quick starts just showing kind of here the processing of the XTS. This is the coded lens on one application server. You can see there is started the JTA transaction with use transaction begin that could be done so with some annotations and then there are the calls to the different servers with like which is like definitions of the client calls to the other server which is this endpoint for web service and the service itself which stays on the other server is annotated with the EJB annotations that expects the transaction is already started when it's called. This is done again transparently in the background by web method is gathering the transaction contacts from the other machine and now resumed here and then the web method is then called in that context and all the work done on both servers are joined together under one transaction. So XTS transactions are the sole based transactions which are goes into flavors in the atomic transaction or the saga based approach as a business activities. With that I have the last thing here where I which is rest AT transactions atomic transactions for over rest for web services. It's similar to what I shown with the web service for sole based managed web services so I don't have any code with me right now prepared so if you are interested in then check in details in an R&R site or in a quick start you can find out and then you can reach us on the forum or also to talk if there are some issues. So and with that we are at the end of our journey through the R&R world of transactions I hope that you will find out you will get some interesting overview of what Narana modules are capable if you will be interested you can check the quick start of Narana where a lot of code are more extensible than what I was showing or you can just check the simple examples that I was showing on my github.