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!