Hi,
I wanted to share with you some fantastic news for those who have either been working with our project for a while or those who might have just recently discovered us. The first version of JBoss Transactions created using our new development environment of GitHub and Maven is available for download right now from:
https://www.jboss.org/jbosstm/downloads/4_17_2_Final
Even better, this version (4.17.2.Final) has made it into the latest branch of AS7! So if you checkout the current version of JBoss AS you will be able to build a version of the app server containing this release!
Here are a few links to help you get started:
1. The projects source code: https://github.com/jbosstm/narayana/
2. The projects documentation repository: https://github.com/jbosstm/documentation/
3. Some quickstarts to get you up and running: https://github.com/jbosstm/quickstarts/
You can checkout these projects using Git (http://git-scm.com/downloads). The following steps show how to obtain the projects source code once you have Git installed (replace the path for documentation or quickstarts):
1. git clone https://github.com/jbosstm/narayana.git
2. git checkout 4.17 (the default branch contains "Narayana" - more on that in later posts...)
To build the project itself, you simply type: ./build.sh install [-DskipTests]
Or, to build either the documentation or quickstarts projects, just type: mvn install
Obtaining the sourcecode for a version of AS7 that contains the new JBoss Transactions is as simple as visiting here:
https://github.com/jbossas/jboss-as/ (the master branch uses our latest release)
As you can tell, the version number has rev'd a little from 4.16.x while we ironed out some of the teething wrinkles with releasing this new version, so for this release we have created a custom release notes link for you that aggregates a couple of version numbers:
https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=12317999
We have also made some considerable enhancements to our documentation pack and with the new quickstarts repo, plus many changes to the tests to make them more robust. The release notes link above has a filter to omit these so you can easily see the new functionality rather than being inundated with numerous related Jiras.
Another major feature is that we have re-introduced for the JDK orb as well as JacORB when using JTS.
The primary theme of this release is collaboration though. We believe that by moving to GitHub we should be much more geared up to accept patches from you. We have a dedicated build server which will check out any "pull request" that you make, build it, and give you feedback as to whether your changes pass our rigorous testing process!
That's about all for now, if you do have any questions I can answer them in the comments or feel free to ask them over on our user or dev forums here: https://community.jboss.org/en/jbosstm?view=discussions and here: https://community.jboss.org/en/jbosstm/dev?view=discussions
Happy developing!
Tom
This is the blog site for the Narayana team. Expect postings on our transaction projects, but also on general transaction issues.
Friday, November 2, 2012
Friday, October 26, 2012
Tuesday, September 18, 2012
XTS Whirlwind Tour
Recently the Transactions Team delivered a training course to the Red Hat support staff to help them support JBossTS. As part of the course I delivered a demo configuring XTS (our Web service Transactions implementation) and debugging common issues. I created myself a script to help make the demo run smoothly. As I was preparing the demo I realized that this could make a great community resource, so I put a little bit more effort in and added some commentary.
Here's the result: http://community.jboss.org/wiki/XTSWhirlwindTour
The XTS Whirlwind Tour covers:
If you find this type of document useful, please let us know as we may be able to do more in the future.
Enjoy!
Here's the result: http://community.jboss.org/wiki/XTSWhirlwindTour
The XTS Whirlwind Tour covers:
- A simple single server scenario
- A simple distributed scenario
- Running an XTS server behind a gateway (Apache)
- Recovery
- Bridging WS-AT to JTA
- Many common issues and how to debug them.
If you find this type of document useful, please let us know as we may be able to do more in the future.
Enjoy!
Monday, June 18, 2012
faking it
Every now and then you find yourself unable to use XA in a situation where you need full ACID guarantees across updates to multiple systems. Once upon a time this occurred mainly in situations where one of your relational databases did not support XA. These days it's more likely to be some newfangled NoSQL store that's not playing nice in the XA ecosystem. When this happens you will more often than not try to convince yourself you can fake it. You probably can't.
XA is a consensus protocol for guaranteeing ACID on transactions spanning multiple resource managers. The two phase commit protocol it uses is a means to that end. For everything to work correctly, it requires that the resource managers make some promises: that they keep changes hidden from other users until the transaction commits and that after the prepare stage they remain able to commit (or rollback) even if they crash before a decision is reached. That's Isolation (usually with a side order of Atomicity) and Durability in a nutshell.
The cheap and cheerful fake version of XA is LRCO. Last Resource Commit Optimization, sometimes called Last Resource Gambit, allows for one non-XA RM in an otherwise entirely XA transaction. By ordering the non-XA resource last in the 2PC processing order you can achieve something that behaves like XA for most scenarios. But close inspection reveals the poor quality of the knockoff goods: LRCO breaks horribly if a crash occurs at certain points in the execution. In such cases inconsistencies between the RMs can arise and reconciling them requires human intervention or complex code. So the savings may not be as good as they first appear.
The more convincing version of LRCO is known as LLRO (Logging Last Resource Optimization) or 1.5 phase commit. In this model you write the transaction manager's log entry to the same database that is being used as the last resource. By making the log write atomic with the commit, you close the timing window during which crashes can cause problems. Which is all well and good if your last resource happens to be a database that can take the logging workload. In cases where it is e.g. a mail server, you're still in trouble.
For the more general case providing the ACID properties yourself in a situation where the resource manager doesn't is hard. Like academic research effort hard. Indeed there are several such research projects in progress right now. Some focus on implementing a custom driver for the resource manager that applies changes against a tx local cache during the transaction, logs them to local disk at prepare and flushes the modifications to the real RM at commit time. This is hard where the resource manager implements complex features, as you wind up needing to reimplement them in the driver or avoid using them in the application code. It's also vulnerable to write conflicts in highly concurrent environments, especially where other clients are accessing the resource manager directly rather than through the custom driver.
The inverse of that model is compensation based transactions. These apply the state changes to the resource manager immediately or at prepare time and then apply additional changes to undo the effects if the transaction needs to roll back. This approach does not offer isolation though - the changes are visible to other users for a time even if the tx is not committed. It's also difficult to generate correct compensation logic for many operations.
All the alternatives to XA have limitations or drawbacks. If your circumstances are such that you can live with those, you may be able to use a different protocol to good effect. But beware the corner cases. You can't fool all the people all the time.
references:
http://stackoverflow.com/questions/8280970/using-xa-with-databases-that-dont-support-it-natively (No I didn't steal the answer, I wrote it.)
http://www.edbt.org/Proceedings/2010-Lausanne/edbt/papers/N128C2.html
http://www.globule.org/?page_id=25
XA is a consensus protocol for guaranteeing ACID on transactions spanning multiple resource managers. The two phase commit protocol it uses is a means to that end. For everything to work correctly, it requires that the resource managers make some promises: that they keep changes hidden from other users until the transaction commits and that after the prepare stage they remain able to commit (or rollback) even if they crash before a decision is reached. That's Isolation (usually with a side order of Atomicity) and Durability in a nutshell.
The cheap and cheerful fake version of XA is LRCO. Last Resource Commit Optimization, sometimes called Last Resource Gambit, allows for one non-XA RM in an otherwise entirely XA transaction. By ordering the non-XA resource last in the 2PC processing order you can achieve something that behaves like XA for most scenarios. But close inspection reveals the poor quality of the knockoff goods: LRCO breaks horribly if a crash occurs at certain points in the execution. In such cases inconsistencies between the RMs can arise and reconciling them requires human intervention or complex code. So the savings may not be as good as they first appear.
The more convincing version of LRCO is known as LLRO (Logging Last Resource Optimization) or 1.5 phase commit. In this model you write the transaction manager's log entry to the same database that is being used as the last resource. By making the log write atomic with the commit, you close the timing window during which crashes can cause problems. Which is all well and good if your last resource happens to be a database that can take the logging workload. In cases where it is e.g. a mail server, you're still in trouble.
For the more general case providing the ACID properties yourself in a situation where the resource manager doesn't is hard. Like academic research effort hard. Indeed there are several such research projects in progress right now. Some focus on implementing a custom driver for the resource manager that applies changes against a tx local cache during the transaction, logs them to local disk at prepare and flushes the modifications to the real RM at commit time. This is hard where the resource manager implements complex features, as you wind up needing to reimplement them in the driver or avoid using them in the application code. It's also vulnerable to write conflicts in highly concurrent environments, especially where other clients are accessing the resource manager directly rather than through the custom driver.
The inverse of that model is compensation based transactions. These apply the state changes to the resource manager immediately or at prepare time and then apply additional changes to undo the effects if the transaction needs to roll back. This approach does not offer isolation though - the changes are visible to other users for a time even if the tx is not committed. It's also difficult to generate correct compensation logic for many operations.
All the alternatives to XA have limitations or drawbacks. If your circumstances are such that you can live with those, you may be able to use a different protocol to good effect. But beware the corner cases. You can't fool all the people all the time.
references:
http://stackoverflow.com/questions/8280970/using-xa-with-databases-that-dont-support-it-natively (No I didn't steal the answer, I wrote it.)
http://www.edbt.org/Proceedings/2010-Lausanne/edbt/papers/N128C2.html
http://www.globule.org/?page_id=25
Tuesday, May 29, 2012
A transactional Android example
OK, so as I announced a couple of days ago, the initial code that allows transactional applications to be written on Android is available. There's even an example demo. Therefore, I thought I'd go through the application and its associated configuration in case people wanted to give it a try in its current state. Also rather than try to address all of the idiosyncrasies of the various Android handsets out there, we'll focus on using the Eclipse emulator this time around.
OK, so let's get started. I'll assume that you've checked out the source for the example (it comes with everything you need, so although you can also check out the source for JBossTS, it's not strictly necessary). As a result, you should have something that looks like:
Now before we take a look at the application code, it's important to remember that we're trying to add transactions to these applications. I won't reiterate all of what this means (I'll leave it as an exercise to the reader to either look through the other articles in this blog or check out transactional resources elsewhere). However, for the purposes of this entry it's important to remember/realise that a transaction needs a durable location where it can store the log to be used in the event of a failure and recovery. In the case of Android, we'll assume this is on an SD card somewhere. In terms of the application and the Android emulator, this has an impact. First, for the emulator we need to create an Android Virtual Device (AVD) and ensure it has an emulated SD card. You can do this easily using the AVD creator:
As you can see, in this case we've selected 512 Meg for the storage. That should be plenty of room for quite a few transactions, especially as most of the time the logs will be created and almost immediately deleted. So you don't have to go overboard with the amount of storage allocated.
Now for the application we need to ensure that it is allowed to access the SD card (external storage). We do that by editing the AndroidManifest.xml:
In this configuration we also need to allow the application to access the internet. This is because JBossTS needs to access the IP address of the device in order to create unique transaction identifiers. We'll look at whether this is something we can change later, but it shouldn't be an issue at this stage.
We're now ready to look at the application. If you've read this blog for a while then you'll know about ArjunaCore and the transactional toolkit within. Not only is it the basis for the work we're doing on STM, but we're using it here to create our application. I won't go into details, because the transactional object is your standard transactional int AtomicObject derived from LockManager and providing operations to read and write the state. It uses nested transactions as well!
So how do we use instances of this transactional int?
Pretty simple. As you can see above, we simply create a new transaction via AtomicAction; create an instance of the AtomicObject; start the transaction and modify the state of the object before committing the transaction. If all goes according to plan, when you deploy this application and run it, you should first see something like:
And then see output similar to below (your transaction id will be different):
That's it! Fairly simple and straightforward. At some point in the hopefully not-too-distant future, I'll get the JBossTS code changes into the mainline code in github and look at a more complex application. This one doesn't cover recovery for instance, and I'd like to more tests. But for now it shows what's possible and the direction in which we're heading. Enjoy!
OK, so let's get started. I'll assume that you've checked out the source for the example (it comes with everything you need, so although you can also check out the source for JBossTS, it's not strictly necessary). As a result, you should have something that looks like:
Now before we take a look at the application code, it's important to remember that we're trying to add transactions to these applications. I won't reiterate all of what this means (I'll leave it as an exercise to the reader to either look through the other articles in this blog or check out transactional resources elsewhere). However, for the purposes of this entry it's important to remember/realise that a transaction needs a durable location where it can store the log to be used in the event of a failure and recovery. In the case of Android, we'll assume this is on an SD card somewhere. In terms of the application and the Android emulator, this has an impact. First, for the emulator we need to create an Android Virtual Device (AVD) and ensure it has an emulated SD card. You can do this easily using the AVD creator:
As you can see, in this case we've selected 512 Meg for the storage. That should be plenty of room for quite a few transactions, especially as most of the time the logs will be created and almost immediately deleted. So you don't have to go overboard with the amount of storage allocated.
Now for the application we need to ensure that it is allowed to access the SD card (external storage). We do that by editing the AndroidManifest.xml:
In this configuration we also need to allow the application to access the internet. This is because JBossTS needs to access the IP address of the device in order to create unique transaction identifiers. We'll look at whether this is something we can change later, but it shouldn't be an issue at this stage.
We're now ready to look at the application. If you've read this blog for a while then you'll know about ArjunaCore and the transactional toolkit within. Not only is it the basis for the work we're doing on STM, but we're using it here to create our application. I won't go into details, because the transactional object is your standard transactional int AtomicObject derived from LockManager and providing operations to read and write the state. It uses nested transactions as well!
So how do we use instances of this transactional int?
That's it! Fairly simple and straightforward. At some point in the hopefully not-too-distant future, I'll get the JBossTS code changes into the mainline code in github and look at a more complex application. This one doesn't cover recovery for instance, and I'd like to more tests. But for now it shows what's possible and the direction in which we're heading. Enjoy!
Sunday, May 27, 2012
Transactional android applications
OK, so it's taken me longer than I expected, but I finally found some time to commit the transactional Android code that I mentioned back in January. Thanks to my JBossWorld keynote preparation, a lot of EAP 6 work and too many meetings to count, I still haven't had enough time to actually commit these changes to the trunk of JBossTS (Narayana). However, rather than continue to delay things, I've decided to check in my edited source to the JBossTS svn repository along with a quick example.
I'll post another article soon to walkthrough the example and its configuration, but if you're interested in checking out the JBossTS source then it's available via svn at https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/mlittle/android and the example at https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/mlittle/TxAndroid. Of course you can build the JBossTS source if you want, but for the sakes of convenience I've included the necessary jars in the example directory.
I'll post another article soon to walkthrough the example and its configuration, but if you're interested in checking out the JBossTS source then it's available via svn at https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/mlittle/android and the example at https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/mlittle/TxAndroid. Of course you can build the JBossTS source if you want, but for the sakes of convenience I've included the necessary jars in the example directory.
Friday, May 18, 2012
Running a WS-AtomicTransaction Enabled Web Service on Openshift
We recently published a video showing you how to deploy a WS-AT enabled Web service on Openshift. The focus of this video is to provide a very simple example that introduces the WS-AT technology and the basics of deploying it to Openshift. The video is based on the wsat-simple quickstart which ships with the JBossAS7 quickstart project. This quickstart and the accompanying video are a great place to start when learning WS-AT. This video also shows you how to enable Web services and WS-AT in Openshift.
In order to keep this quickstart simple, I have focused on demonstrating how the WS-AT protocol works and the Java API to it. As a result, I needed to omit several features that you would expect in a real application. The XTS demonstrator provides a much fuller example of how to use WS-AT. Although more complete, it has a steeper learning curve for those new to WS-AT.
The limitations are as follows:
1. No backend resource. In a real application, it is likely that your Web service will be manipulating some transactional state. For example, it could be updating a database or sending a JMS message. This quickstart uses a mock resource that is neither transactional nor persistent. For an example of how to write and interface with transactional resources, you can take a look at the XTS demonstrator.
2. No WS-AT to JTA bridging. Using the JBossTS TXBridge technology, WS-AT transactions can be seamlessly bridged onto backend JTA transactions (and vice versa). This allows you to use WS-AT as in integration technology for creating a distributed transaction. WS-AT has proven interoperability with many vendors and in some situations it is the only way to create a distributed transaction in a heterogeneous vendor environment. WS-AT also uses SOAP over HTTP as the transport, which can overcome some integration problems that, say a binary protocol, cannot. The TXBridge is currently a technology preview and will not be supported in JBoss EAP 6.0. Therefore it could not be used in this quickstart. The TXBridge does ship with both JBossAS 7.x and EAP 6.0 so you can try it out. For an example, please see the TXBridge quickstart.
3. No recovery. The quickstart does not implement the required hooks to support crash recovery. This is a complex subject and one that is covered by the XTS demonstrator.
4. Multiple Services. WS-AT is a consensus protocol which implies that it is designed to support multiple parties. This quickstart only uses a single service, but could quite easily be modified to use multiple. Again the XTS demonstrator provides an example of this in action.
In order to keep this quickstart simple, I have focused on demonstrating how the WS-AT protocol works and the Java API to it. As a result, I needed to omit several features that you would expect in a real application. The XTS demonstrator provides a much fuller example of how to use WS-AT. Although more complete, it has a steeper learning curve for those new to WS-AT.
The limitations are as follows:
1. No backend resource. In a real application, it is likely that your Web service will be manipulating some transactional state. For example, it could be updating a database or sending a JMS message. This quickstart uses a mock resource that is neither transactional nor persistent. For an example of how to write and interface with transactional resources, you can take a look at the XTS demonstrator.
2. No WS-AT to JTA bridging. Using the JBossTS TXBridge technology, WS-AT transactions can be seamlessly bridged onto backend JTA transactions (and vice versa). This allows you to use WS-AT as in integration technology for creating a distributed transaction. WS-AT has proven interoperability with many vendors and in some situations it is the only way to create a distributed transaction in a heterogeneous vendor environment. WS-AT also uses SOAP over HTTP as the transport, which can overcome some integration problems that, say a binary protocol, cannot. The TXBridge is currently a technology preview and will not be supported in JBoss EAP 6.0. Therefore it could not be used in this quickstart. The TXBridge does ship with both JBossAS 7.x and EAP 6.0 so you can try it out. For an example, please see the TXBridge quickstart.
3. No recovery. The quickstart does not implement the required hooks to support crash recovery. This is a complex subject and one that is covered by the XTS demonstrator.
4. Multiple Services. WS-AT is a consensus protocol which implies that it is designed to support multiple parties. This quickstart only uses a single service, but could quite easily be modified to use multiple. Again the XTS demonstrator provides an example of this in action.
Subscribe to:
Posts (Atom)