Showing posts with label raspberry pi. Show all posts
Showing posts with label raspberry pi. Show all posts

Sunday, March 31, 2013

STM, vert.x and the Pi Part 1

Given other priorities (aka 'my day job'), I'm slowly working my way through another pet project I've had for a while: adding transactions, and specifically STM, to vert.x. Of course at the moment I also try to add an influence from my other pet project, the Raspberry Pi, so I'm doing it on the Pi as much as possible. OK, it may not be the fastest machine on the block, but it's a lot of fun!

We've had STM in Narayana for a while, so I won't cover the basic again. I'm also not going to cover any Pi-related set up: by this point you should know enough to do this yourself. So let's start with cloning the most recent version of Narayana:


Make sure your path and JAVA_HOME are set so we're using JDK 7:

 
Next let's build the components we need for STM:


Don't forget that this is going to take a while, so maybe time to go grab a coffee, read a book, play with your kids, or watch an episode of Lost.


With that build complete, we've already run a lot of STM examples in the form of unit tests. However, let's take a simple example:

import java.io.IOException;

import org.jboss.stm.annotations.Transactional;
import org.jboss.stm.annotations.ReadLock;
import org.jboss.stm.annotations.WriteLock;
import org.jboss.stm.internal.RecoverableContainer;

import com.arjuna.ats.arjuna.AtomicAction;

/**
 * @author Mark Little
 */


public class Example
{  
    @Transactional
    public interface Atomic
     {
     public void change (int value) throws Exception;
       
     public void set (int value) throws Exception;
       
     public int get () throws Exception;
    }
   
    @Transactional
    public class ExampleSTM implements Atomic
     {  
        @ReadLock
     public int get () throws Exception
     {
         return state;
     }

        @WriteLock
     public void set (int value) throws Exception
     {
         state = value;
     }
       
        @WriteLock
     public void change (int value) throws Exception
     {
         state += value;
     }

     private int state;
    }
   
    public void testExample () throws Exception
    {
        RecoverableContainer theContainer = new RecoverableContainer();
        ExampleSTM basic = new ExampleSTM();
        Atomic obj = null;
       
        try
        {
        obj = theContainer.enlist(basic);
        }
        catch (final Throwable ex)
        {
        ex.printStackTrace();
           
        return;
        }
       
        AtomicAction a = new AtomicAction();
       
        a.begin();
       
        obj.set(1234);
       
        a.commit();

    System.out.println("Should get() 1234 after commit: "+obj.get());
       
        a = new AtomicAction();

        a.begin();

        obj.change(1);
       
        a.abort();

    System.out.println("Should get() 1234 after abort: "+obj.get());
    }

    public static void main (String[] args)
    {
    Example ex = new Example();

    try
    {
        ex.testExample();
    }
    catch (final Exception e)
    {
        e.printStackTrace();
    }
    }
}


Stick this at the same level of Narayana if you want to use the same CLASSPATH as here:

narayana/ext/jboss-logging.jar:narayana/ArjunaCore/arjuna/target/test-classes:narayana/common/target/common-5.0.0.M3-SNAPSHOT.jar:narayana/STM/target/core-5.0.0.M3-SNAPSHOT.jar:narayana/ArjunaCore/txoj/target/txoj-5.0.0.M3-SNAPSHOT.jar:narayana/ArjunaCore/arjuna/target/arjuna-5.0.0.M3-SNAPSHOT.jar:.

After compiling, run the example and you should see the following:


Despite what I said at the start of this entry, there's a distinct lack of vert.x involved here at the moment. That's because there are a few changes we need to make to the STM implementation to make it easier to share transactional objects between address spaces. This is all stuff that's available "natively" in TXOJ, so developers could use that API immediately. However, the STM approach simplifies a lot so once those additional features from TXOJ are integrated there, we'll have a follow up article to discuss what, how and why.

Sunday, December 23, 2012

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.