The RapidPM Blog

We are speaking Java, because it is a great pleasure for us.

EJB Transaction Rollback and Timers

Introduction

Today I was a little confused when a colleague of mine tried to explain to me the transaction control directives our application depends on. The tough part was to consider all the possible rollback scenarios. To get more insight into rollback behaviour, I created a simple demo project.

The project can be found on github. It demonstrates all possible cases I could think of with respect to transaction rollback and programmatic timer manipulation. I have added TODO markers in places you choose between different scenarios. I also added a comment on what is expected to happen and why.

It works with glassfish 3.2 and 4.1. Feel free to try it out and please share your thoughts. Please keep in mind, however, this project was primarily designed to run on both versions of glassfish.

The specification (JSR-318 - EJB 3.1) can found at the JCP site. I added references to specification, which relate to this document.

EJB Transaction Rollback - When does it happen?

My primitive assumption was, that if the method that spans a transaction (e. g. by declaring TransactionAttribute.REQUIRES_NEW) terminates with an exception, the associated transaction must be rolled back. However, this is not necessarily true.

Actually it depends on the type of the exception. Transactions only rollback if the exception being thrown is marked for rollback (cf. chapter 14.3.1, Table 15).

By the default, all checked exceptions are marked as rollback=false, whereas the unchecked exception are marked as rollback=true. You can explicitly specify rollback behaviour on exceptions with @ApplicationException(rollback = true / false).

If you have an EJB that uses another EJB injected via @EJB / @Inject and the invoked method executes of the same transaction (e. g. because of TransactionAttribut.REQUIRED), this method can also induce a rollback of the transaction if it throws an appropriate exception.

This means a business method may throw an exception and have the transaction committed at the same time. Conversely, by using another EJB a transaction can be rolled back even if you catch its exception. Both of these cases are shown in the demo project.

EJB Transaction Rollback and timers

Transaction rollback also influences timeout methods (i. e. methods annotated with @Schedule / @Timeout). If the transaction used for a timeout method shall be rolled back, it is required by the specification, that the method invocation will be retried at least once (cf. chapter 18.4.3). Glassfish retries the invocation 5 seconds later. However, if the second invocation induces a rollback as well, the timer will be expunged. That means you will loose all future invocation of that timer.

The specification actually disallows timeout methods to throw application exceptions (cf. chapter 18.2.5.3), however glassfish can cope with that. Timeout method invocation is retried if either the method throws an exception or the associated transaction is marked for rollback. A timeout method can also have a committed transaction even though it throws an exception. However, since this is not allowed by the spec, its behaviour is specific to the application server in use.

For glassfish, retrying timeouts and expunging timer can be configured in the admin interface (screenshot).

Programmatic manipulations of timers with the help of @Resource TimerService are also subject to transaction rollback (cf. chapter 18.2.8). Therefore registering a new @Timeout or cancelling and an existing Timer will also be reverted of the corresponding transaction is rolled back.

Tinkerforge: Automatic Bricklet Setup

In the last couple of month i had several times small TinkerForge systems with different bricklet configurations which were programmed in Java. And in order to work with them i always had to do the „BrickViewer-Find-UID-Dance“ which at some point really annoyed me.

The problem of a changing setup will also occur if you have a broken bricklet and replace it with a new one. You may say „Ok, that is prototyping“. But the idea behind TinkerForge is to write your prototype and if your are ready transfer it to new hardware for production without any change. It is basically the same in Java „Write once, run everywhere“ and that is currently not the case. This problem has also influence of your application design where you at one point outsource your bricklet uids into a property file so that you can easily reconfigure it if something has changed. But from my point of view that should not be necessary and it should be possible to do that automatically.

In order to do that i had taken a quick look at the TinkerForge-API where i found that every bricklet class (FYI: extends Device) has a public static final int field DEVICE_INDENTIFIER. As the name suggests this is the identifier of the device which is not needed to be used by programmers. But in this case and also in case of Mocking Devices we can make an exception. So why is this important?
The point is that the IPConnection class has an enumeration listener which is triggered by every bricklet connected to the IPConnection when IpConnection.enumerate() is called. And with that we can discover which bricklet-uid-combination is connected.

So the idea is very simple: (1) Create a simple lookup table of device identifier to bricklet classes so that you can use the (2) enumeration listener to look up the connected bricklet class. In order to do the first step i am using the Guava library reflections because it is currently not possible with plain Java to find all subclasses via the reflection API. In the example above i also introduced a small helper map so that in the end an application can really benefit of it. Especially if you are using more bricklets of the same type.

public class BrickletReader {
  public static void main(String[] args) throws Exception {

    // (1) Find all Subclasses of Device
    Reflections reflections = new Reflections("com.tinkerforge");
    Set<Class<? extends Device>> subTypesOf = reflections.getSubTypesOf(Device.class);

    //Read all DeviceIdentifier into Map<Identifier, Class>
    final Map<Integer, Class<? extends Device>> allDeviceIdentifierMapping = new HashMap<>();
    for (Class<? extends Device> deviceClass : subTypesOf) {
      try {
    	Field deviceIdentifier = deviceClass.getDeclaredField("DEVICE_IDENTIFIER");
    	allDeviceIdentifierMapping.put(deviceIdentifier.getInt(null), deviceClass);
      } catch (IllegalAccessException | NoSuchFieldException e) {}  //Ignore
    }

    //Application bricklet class to uid map
    final BrickletUidMap brickletUidMap = new BrickletUidMap();

    // (2) Lookup connected bricklets with an EnumerateListener
    IPConnection ipConnection = new IPConnection();
    ipConnection.connect("localhost", 4223);
    ipConnection.addEnumerateListener(
    		(uid, connectedUid, position, hardwareVersion, firmwareVersion, deviceIdentifier, enumerationType) -> {
    		  if (enumerationType == IPConnection.ENUMERATION_TYPE_DISCONNECTED) {
    			return;
    		  }

    		  //Add class uid combination to map
    		  Class<? extends Device> aClass = allDeviceIdentifierMapping
    				  .get(deviceIdentifier);
    		  brickletUidMap.put(aClass, uid);
    		}
    );

    ipConnection.enumerate();

    //Example: 2 temperature and one ambientlight bricklets
    BrickletTemperature temperature1 = new BrickletTemperature(brickletUidMap.getBrickletUid(BrickletTemperature.class), ipConnection);
    BrickletTemperature temperature2 = new BrickletTemperature(brickletUidMap.getBrickletUid(BrickletTemperature.class), ipConnection);
    BrickletAmbientLight ambientLight = new BrickletAmbientLight(brickletUidMap.getBrickletUid(BrickletAmbientLight.class), ipConnection);
  }
}

Conclusion

With the code above you can achieve now several things:

  • Improve coding time (and in terms of clean code DRY)
  • Improve your application robustness (Write once, run everywhere)
  • No more manually setup of bricklets uids
You can find the code here

AngularJS directives put to use - Part 2

Introduction

This is the follow up of AngularJS directives put to use - part 1. In the last article I showed how to build a directive for Bootstrap's navigation bar. While this hugely saves redundant code and totally simplifies adding new navigation entries, I'll show something even more practical and useful in this article.

I am developing an application for tracking ones expenses. Thus it is only natural to display a lot of currency values. AngularJS provides a fantastic means to display bare currency values: the currency filter. With the introduction of AngularJS 1.3 Google also improved the currency filter. Now you can specify how many decimal digits you want to be displayed.

This greatly helps to uniformly display currency values (especially depending on your locale) but still the result is a bare string. When tracking ones expenses there are naturally not only expenses, i. e . negative values. To spend money you first have to earn it. Therefore, you also have positive values. I wanted them to be displayed differently. Negative values should have a red font, positive values should have a green font.

The primitive approach

First I came up with a very primitive approach. Wherever I displayed currency values, I used ng-class to decide with class to apply depending on the value to display.

<td ng-class="{'positive': x.amount >= 0,
                  'negative': x.amount < 0}">{{x.amount| currency }}</td>

This starts to get annoying pretty soon when all over your application markup like this pops up. I thought there had to be a more convenient way - and there was! You can guess it: directives to the rescue.

I build simple directive that encapsulated the distinction between positive and negative values and the application of respective css class.

A little more sophisticated approach

var myDirectives = angular.module('myApp.directives', []);

myDirectives.directive('accentuatedCurrency', function($filter) {

    function link(scope, element, attrs) {

        var text = attrs.accentuatedCurrency;

        var value = parseFloat(text);
        if (value < 0) {
            element.addClass('negative');
        } else {
            element.addClass('positive');
        }

        var formatted = $filter('currency')(value);
        element.text(formatted);

    }

    return {
        restrict: 'A',
        link: link
    };
});

With this directive I was able to simply use the following snippet:

<td accentuated-currency="{{x.amount}}"></td>

This made formatting currency values depending on the signum a breeze. However, some time later I had to learn that this directive wasn't as useful as I thought. This approach effectively circumvented the two-way-databinding AngularJS provides, because the decision which css class is to be applied was only performed once, namely when the page is initially constructed. Subsequent changed to x.amount where completely ignored.

The final approach

Similarly to the approach of the last article I had to introduce a listener, which reacts to the change of x.amount and updates the applied css class respectively.

var myDirectives = angular.module('myApp.directives', []);

myDirectives.directive('accentuatedCurrency', function($filter) {

        function link(scope, element, attrs) {

            function setAccentuatedValue(changed) {
                var value = parseFloat(changed);

                if (value < 0) {
                    element.addClass('negative');
                    element.removeClass('positive');
                } else {
                    element.addClass('positive');
                    element.removeClass('negative');
                }

                var formatted = $filter('currency')(value);
                element.text(formatted);
            }

            scope.$watch(attrs.accentuatedCurrency, function (value) {
                setAccentuatedValue(value);
            });

        }

        return {
            restrict: 'A',
            link: link
        };
}]);

Now the linking function registers a listener to be executed upon a value change instead of immediately applying a css class. That way even if the value bound x.amount changes, the format changes with it.

As with the last example, using this directive saves redundant code and makes your markup a little more DRY. I hope I could demonstrate another practical use of directives.