Raspberry flavoured transactions

I got asked by a few different people lately about how to build Narayana on a Raspberry Pi. Well it's pretty easy and you don't even need one of the upgraded Model Bs with 512Meg of memory. Here are the steps you need to follow:

• I'm going to assume you know how to set up your Pi. I'm also going to assume that you're using the default pi account.
• You'll need to install OpenJDK (sudo apt-get install openjdk-6-jre openjdk-6-jdk), maven and git (maven/git sudo apt-get install maven2 git). Other optionals include emacs (of course!) and your favourite databases, but we'll leave those for the curious.
• Then let's clone the source tree ... git clone https://github.com/jbosstm/narayana

• Then it's the usual steps to build, although due to some issues with idl on the Pi, we can't run JTS just yet using the ORB within the JDK, so let's go with the JTA implementation only ... ./build.sh clean install -P jta
• After that, sit back and wait ... for a long time, so be patient.

• It should take about 2 hours to complete, which is significantly slower than the 30 minutes or so that it can take on your laptop to build everything. (If you try to build everything, then it'll be closer to 5 hours!) But hey, the Pi is underpowered compared to that hardware and if you're looking to use a Pi then hopefully you've already taken that into consideration! And yes, you will see some warnings and maybe a timing error or two during the build execution of some tests, but nothing to be concerned about. We'll look into these and see if there's anything we can do to tidy-up the build in the future.

And that's it! Congratulations, you've just built and tested Narayana on your Raspberry Pi. And apart from the time it takes to build, there really wasn't much to it, now was there?

Note, if you want to build the JTS then you do have the option to use JacORB. However, at the moment this requires you to edit a number of the pom.xml files to remove the dependency on idlj.

JBoss Transactions 4.17.2.Final released

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

Transactions and NoSQL

Just a quick cross-posting in case people are interested.

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:

• 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.

I hope you find this useful. Remember, this is a community document so please get involved, comments are strongly encouraged!

If you find this type of document useful, please let us know as we may be able to do more in the future.

Enjoy!

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

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!

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.

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.

Transactions and parallelism and actors, oh my!

I wanted to cross-post an article I just wrote on the benefits of transactions in a massively parallel environment (not just a distributed system), not just because some may find it interesting in itself, but also because it references some of the work we've been doing in the project over the past decades. I'm hoping that as we do more work on STM and mobile transactions, to name but two areas of work, that we'll bring some of the techniques that were written about 20+ years ago to a new audience and maybe out of the realm of research. We have got a great transaction system and team here that is second to none. I'm convinced that just as Arjuna pushed the boundaries of standards and adoption of transactions for the past decades, so too can JBossTS/Narayana into the future.

Update to STM API

A few weeks ago we saw details of the new optimistic concurrency control (MVCC) for the STM implementation. At the time I mentioned that the syntax for using pessimistic and optimistic was different and also slightly more verbose than it really needed to be. So there have been a few changes recently and although it's not quite the way I want it, it's worth discussing now to at least give you an idea of where we are going with things. Especially important if you're trying to develop something using the STM and the previous examples as a template, since although all of those original classes and methods continue to exist, they may have moved packages!

I'll assume that you can compare and contrast by looking at the original posting, so here's how you create and use objects now:

Container theContainer = new Container();

Sample1 obj1 = theContainer.create(new SampleImple(10));

Sample1 obj2 = theContainer.create(new SampleImple(10));

Sample1 obj3 = theContainer.clone(new SampleImple(), obj1);

Sample1 obj4 = theContainer.clone(new SampleImple(), obj2);

It no longer matters whether they are @Pessimistic or @Optimistic (the default) - the syntax remains the same. Here we have two objects, obj1 and obj2 and two clones (copies) of them, obj3 and obj4. They're all recoverable (state will not survive a machine crash), since that's the default behaviour for Container, but that can be changed via the constructor which allows for PERSISTENT or RECOVERABLE to be specified at creation time.

You can probably guess where further improvements are going to happen. For a start, the fact that the clone method takes a "blank" instance to copy the state into is necessary, but it would be better if it could be inferred. In addition, there are some state management aspects of the implementation that need tidying up because they currently escape through into the application. However, these are both fairly straightforward aspects to fix and the plan is to get them finalised soon. But for now, these changes should be sufficient to try things out. Enjoy!

The Future of XTS

Last September I took over the great work that Andrew Dinn has been doing leading the XTS (Web service transactions) project. Since then I've been having a think about where we should be taking the project over the next few years. In this post I want to present our ideas to the community. Hopefully this will give you an idea of where we are going with XTS and give you an opportunity to provide feedback. I'll also refer to work planned for the Narayana project (AKA JBossTS), where it also applies to XTS.

About Me
First of all I'll take this opportunity to introduce myself. I've worked in the field of transactions and Java middleware for over 10 years. I started out in 2001 as a software engineer on the XTS project, recently after it was founded by Hewlette Packard. Here I helped to develop the industry's first Web service transaction implementation. In those days we were implementing the BTP standard. Since then I headed up the consultancy arm of Arjuna Technologies, helping high-profile customers deploy JBoss Transactions, JBossWS and also Arjuna's Cloud Computing product. In late summer of 2011 I made the jump to Red Hat to lead the XTS project. I have also received a PhD in middleware and non-repudiation from the University of Newcastle upon Tyne, where I now hold the role of Visiting Research Fellow. In this role I teach JEE and distributed transactions as part of a masters course.

After reviewing where the XTS project currently stands we've had a good think about what areas of improvement we should be focusing on over the coming months and years. We've found that these improvements tend to fall into one of four 'themes'; usability, modernization, streamlining and consistency.

Usability
Improving usability is our number one priority. In particular we will be introducing quickstarts (JBTM-870) and making significant improvements to the XTS java API.

Currently we have a fantastic demonstrator that shows the developer how to use, pretty much, every feature of XTS. The problem is that it is not an easy place to start for those new to XTS. Recently we added a number of basic quickstarts to the JBossAS 7 quickstart project. These quickstarts are designed as a place to start when beginning to use XTS. We also have plans to provide additional quickstarts as part of the Narayana quickstart project (JBTM-870). These quickstarts will focus on more advanced features, such as recovery. These quickstarts will adhere to the same strict guidelines imposed by the JBossAS team. This will bring a high level of quality as well as familiarity. We also intend to provide unit tests with every quickstart; and those in the Narayana quickstart project will undergo continuous integration on our Hudson servers (JBTM-1068). This should ensure our quickstarts always work in the intended environment. We have an idea of what quickstarts we should initially provide, but we feel it would be best to be community driven in the future. So if you have an idea for a quickstart, or maybe you have one to contribute, then please get in touch on the forum.

The biggest changes around usability are coming as part of our new sub-project; currently named the 'TXFramework'. The TXFramework is a new and novel framework for writing portable ACID and NoACID transactional applications. It provides an abstract annotation based API for specifying transactional requirements. This decouples the application logic from the actual transaction model used (WS-AT, REST_AT, JTA, etc). It also removes a lot of boilerplate code that's currently needed by WS-AT and WS-BA services. The TXFramework also provides seamless bridging between different transaction protocols. This subject could cover many blog postings, so I won't discuss it in any more detail here. Stay tuned for more posts on this subject in the coming months. I'll also be presenting the TXFramework at JUDCon2012:Boston on the 25th June. Hope to see you there!

Modernisation
The next focus is around modernization. There's been a lot of exciting new technology emerging over the last few years and we are making many improvements to take advantage of it. In particular, Arquillian and Git.

The XTS functional tests need to run in a container. Before JBoss developed the Arquillian project, we were forced to create an in-container test-runner to run our functional tests. By migrating to Arquillian we are now able to remove this test-runner code and take advantage of additional benefits that Arquillian brings. In particular we can run any/all of the XTS tests from with the IDE as regular JUnit tests. Arquillian also manages the setup and teardown of the test environment, making it a lot easier to run the tests. This improvement is going to remove a lot of code from the XTS codebase and bring great simplification to the way we write and run tests. JBTM-954, JBTM-955, JBTM-956

Narayana and Blacktie were recently migrated from SVN to Git and Github (See here). Git has been gaining a lot of traction recently in the world of open source and most JBoss projects have now made the leap. After reviewing the benefits of moving, we decided now was the time to make the jump. In particular it was the improvements to collaboration provided by Git and GitHub that made us feel that this was the right thing to do. If you are a contributor, you're going to find it a lot easier to get involved with XTS and Narayana.

We've also moved the entire Narayana project to maven, which is making it a lot easier for our contributors to get up and running quickly and is making it easier for us to maintain our build system. We're also beginning to use JaCoCo to check our test coverage JBTM-952. This ensures that XTS is fully tested and helps find redundant code.


Streamlining
We are doing some streamlining too to the XTS code base. We are taking two approaches here; as mentioned above we are using JaCoCo to help find redundant code. This should cut down the amount of code we need to maintain and help contributors get up to speed more quickly as they don't need to sift through unused code (JBTM-741). The second approach we are taking is to replace code with third party libraries where we can be sure that they will provide an equal or better implementation. For example, as stated above we are in the process of replacing our test-harness code with Arquillian (JBTM-953).


Consistency
Being productive and helping our contributors be productive is very important to us. Having to switch between and understand different practices when working with our projects does not help with this goal. Therefore, we are aiming to bring as much consistency as we can between XTS and Narayana and to some extent between Narayana and the other JBoss projects. A move to improved consistency also brings with it an opportunity to re-use ideas that have been proven elsewhere. In particular, our quickstarts are now in the process of being moved to a single repository and follow the strict guidlines set out by the JBossAS team. The XTS codebase is being re-structured to follow the default maven layout (JBTM-968). This should make it easier for new contributors to follow our layout.

Getting Involved
Of course, we would love the community to get involved with XTS and the Narayana project. I mentioned many pieces of work in this post; you should follow the Jira issue links and vote up the ones that matter to you. If you have an idea for something you would like to be included, please start a discussion on the Narayana forum. You can also fork our GitHub projects if you'd like to get involved with the coding side.

Transactions and NoSQL - not reinventing the wheel!

It's nice to see some NoSQL solutions recognising that they need transactions (or extended transactions) and rediscovering the work that the transactions community (ourselves included) have been working on for a few decades! This presentation is interesting, but frustrating in a few places, e.g., the discussion around the viability of nested transactions for long duration interactions, in general the discussion around Sagas, and the Q&A at the end where the glossing over of technical aspects during the talk really lead to confusion.

However, that aside, it's not a bad overview of the needs for long duration, compensation based transactions and references a few of the important papers and research in this space going back several decades. Of course if you've been reading this blog long enough or watching the work we've been doing for a while, you'll know about others, including:

• the compensation REST transactions work;
• a history of extended transactions;
• a comparison of two of the original standards efforts in the area of compensation transactions;
• a couple of presentations on early standards effort around Web Services and transactions;
• an overview of the wider expanse of work that has been done around extended transactions, workflow, messaging, choreography etc.

The reference to the Sagas pattern that is mentioned, but forgotten, in the presentation I mentioned originally can be found here. It's nice to see that at least in the case of this NoSQL implementation, the engineers are willing to see what's gone before and learn from it. And if you want to look at implementations (and frameworks) that do much of this already, then take a look at JBossTS - without you having to write your own do/undo log!

Optimistic STM

It's been a while since I last posted anything on the Software Transactional Memory work that's been going on in JBossTS (aka Narayana). At that time we had everything in place for you to write transactional applications that have all of the ACID properties or, more common for STM, without the D. Per object concurrency control is done through locks and type specific concurrency control is available. You can define locks on a per object and per method basis, and combined with nested transactions this provides for a flexible way of structuring applications that would typically not block threads unless there is really high contention:

@Transactional

public class SampleLockable implements Sample

{

public SampleLockable (int init)

{

_isState = init;

}

@ReadLock

public int value ()

{

return _isState;

}

@WriteLock

public void increment ()

{

_isState++;

}

@WriteLock

public void decrement ()

{

_isState--;

}

@State

private int _isState;

}

If you recall from previous articles, all but the @Transactional annotation are optional, with sensible defaults taken for everything else including locks and state. And you create and use instances fairly simply:

RecoverableContainer theContainer = new RecoverableContainer();

Sample obj1 = theContainer.enlist(new SampleLockable(10));

However, the locking strategy we had originally was pessimistic. As I mentioned separately:

"Most transaction systems utilize what is commonly referred to as pessimistic concurrency control mechanisms: in essence, whenever a data structure or other transactional resource is accessed, a lock is obtained on it as described earlier. This lock will remain held on that resource for the duration of the transaction and the benefit of this is that other users will not be able to modify (and possibly not even observe) the resource until the holding transaction has terminated. There are a number of disadvantages of this style: (i) the overhead of acquiring and maintaining concurrency control information in an environment where conflict or data sharing is not high, (ii) deadlocks may occur, where one user waits for another to release a lock not realizing that that user is waiting for the release of a lock held by the first."

And the obvious alternative to this approach is optimistic:

"Therefore, optimistic concurrency control assumes that conflicts are not high and tries to ensure locks are held only for brief periods of time: essentially locks are only acquired at the end of the transaction when it is about to terminate. This kind of concurrency control requires a means to detect if an update to a resource does conflict with any updates that may have occurred in the interim and how to recover from such conflicts. Typically detection will happen using timestamps, whereby the system takes a snapshot of the timestamps associated with resources it is about to use or modify and compares them with the timestamps available when the transaction commits."

Therefore, you can probably guess what's just been added to our STM implementation? Yes, that's right ... optimistic concurrency control! In line with the annotation based approach we've used so far, there are now two new annotations: @Optimistic and @Pessimistic, with Pessimistic being the default. These are defined on a per interface basis and define the type of concurrency control implementation that is used whenever locks are needed:

@Transactional

@Optimistic

public class SampleLockable implements Sample

{

public SampleLockable (int init)

{

_isState = init;

}

@ReadLock

public int value ()

{

return _isState;

}

@WriteLock

public void increment ()

{

_isState++;

}

@WriteLock

public void decrement ()

{

_isState--;

}

@State

private int _isState;

}

And that's it. No other changes are needed to the interface or to the implementation. However, at present there is a subtle change in the way in which you create your objects. Recall how that was done previously and then compare it with the style necessary when using optimistic concurrency control:

RecoverableContainer theContainer = new RecoverableContainer();

Sample obj1 = theContainer.enlist(new SampleLockable(10));

Sample obj2 = theContainer.enlist(new SampleLockable(10),

theContainer.getUidForHandle(obj1));

In the original pessimistic approach the instance obj1 can be shared between any number of threads and the STM implementation, along with JBossTS, will ensure that the state is manipulated consistently and safely. However, with optimistic concurrency we need to have one instance of the state per thread. So in the above code we first create the object (obj1) and then we create a copy of it (obj2), passing a reference to the original to the container.

It is likely that the API for this will change soon in order to unify optimistic and pessimistic: the aim is to make it as opaque as possible to the application so you only have to modify an annotation when you want to change the implementation. One other thing that we're considering is changing the implementation dynamically, perhaps based on monitored metrics for contention. But for now that's it and it's all available in the Narayana git repository.

connecting the dots

Hmm, looks like it's 2012 already, which means we're overdue for another rant. Today's lecture topic is the perils of trying to replace or do without bits of code that you don't understand.

Programming in the large is all about abstraction, loose coupling and separation of concerns. Java EE promotes the ability to use complex functionality without understanding how it is implemented. As long as you follow the instructions this works surprisingly well. With an app server at your disposal you require only the sketchiest understanding of distributed transactions to write code that consumes a message and updates a database in an ACID fashion. Which on the whole is a good thing, since not all that many people actually want to understand all the plumbing that makes it work. There is a snag though: this apparent simplicity can cause some users to think the Java EE container is not doing all that much work and can easily be replaced or done without. Likewise it makes it difficult to tell the difference between a full fledged container that will support the functionality you need and a cut down framework or lightweight container that may not.

Let's debunk a few myths...

Spring is not a JTA.

It's an abstraction layer on top of a transaction manager, not an implementation of one. For transactions involving only a single resource, it simply delegates the hard bits to that resource manager - so called 'native transactions'. Simple, fast and mostly adequate if you need only a single resource. You don't get transaction lifecycle events, but you're probably using an ORM that provides the equivalent of the beforeCompletion hook for its cache anyhow.

For transactions with more than one resource, you need to wire in a real transaction manager to Spring. You can do this with bitronix, atomikos or JBossTS, usually just by specifying the right TransactionManager and UserTransaction implementation bean classes. But your problems don't end there, because...

Spring is not a JCA.

The roles, responsibilities and relationship between the JTA and JCA components of an app server are critical considerations when you're trying to do without one. The JTA manages transaction lifecycle - begin/commit/rollback. Most importantly, it make appropriate calls on any enlisted XAResources as the transaction progresses. But here is the bit that most users don't pay attention to: A JTA does not magically know what resources you want to participate in the transaction. Telling it that is the JCA's job.

In a full on app server, the JCA manages connections to resource managers such as databases and message queues. If you deploy those drivers/connectors in a manner that identifies them as XA enabled, the JCA ensures that they are correctly associated with the transaction. Application code simply e.g. looks up the JNDI name for a connection pool and calls getConnection(). The JCA intercepts the call, get the XAResource for the connection and passes it to the transaction manager.

In some cases you don't need a full JCA. You can often make do with a transaction manager aware XA connection pool, which is essentially a subset of the JCA functionality. But you can't get away with only an XA aware driver or a non-XA connection pool. Trying to do that leads to some interesting behaviour: your app will deploy and run, but you have a transaction and a connection that know nothing about one another. Committing or rolling back the transaction won't commit or rollback the work in the database. oops.

So, you also need to wire in a JCA or suitable connection pooling implementation. Most 'standalone' JTA implementations ship with a simple connection management solution that is suitable for light use. The one in JBossTS is called the TransactionalDriver. For serious deployments you want IronJacamar or some other JCA that has robust and fast connection management.

So now you have wired up your JTA and JCA in Spring, but you are still not done because...

The standard contract between JTA and JCA does not include recovery management setup. Wiring up resources for crash recovery requires a proprietary solution that differs for each transaction manager. The connection manager that ships with the transaction manager may do this more or less automatically, but third party JCAs or XA aware connection pools probably won't. So, go read the transaction manager documentation and write a few test cases.

phew, that was a lot of work, wasn't it? Spring is good at what it does, but its not an out of box replacement for all the transactional plumbing in a Java EE app server. Nor is tomcat - you'll have much the same steps to perform there. In both cases it is possible, but not as simple as unzipping and starting JBossAS. Do you really want to make your life harder than it has to be?

Transactional Android coming soon!

I spent some time this Christmas porting JBossTS to run on Android. It's pretty much done, with the exception of a few workarounds that I need to fix properly over the next few weeks, when I find the time. But once I check this code into the repository, you'll be able to write your own transactional Android applications. Unfortunately I can't guarantee which version this will be in at the moment, but if it is going to take me too long to do the merges then I may create a branch in svn that interested people can just pull from directly, with the usual caveats. If time allows, I may say something about this at JUDCon India too!