If Actions::errorCallingAction catches an Exception, it will execute the errorAction. If a java.lang.Error such as NoClassDefFoundError occurs, however, the errorAction is not executed.
One might argue that this is on purpose because Errors shouldn't be caught and processed. ChoicePseudoState::executeActions, however, catches Throwable, logs a warning and does not rethrow it.
Therefore, a java.lang.Error is not noticed by the transaction manager and the transaction is committed as if no Error had occurred. This missing rollback causes corrupt data due to transactions being executed only partially.
This issue is not only a theoretical one which might occur, it actually did several times using spring-statemachine-core-2.0.3.RELEASE.
I think this could be fixed by executing the errorAction in Actions::errorCallingAction for all kinds of Throwables.
If Actions::errorCallingAction catches an Exception, it will execute the errorAction. If a java.lang.Error such as NoClassDefFoundError occurs, however, the errorAction is not executed. One might argue that this is on purpose because Errors shouldn't be caught and processed. ChoicePseudoState::executeActions, however, catches Throwable, logs a warning and does not rethrow it. Therefore, a java.lang.Error is not noticed by the transaction manager and the transaction is committed as if no Error had occurred. This missing rollback causes corrupt data due to transactions being executed only partially.
This issue is not only a theoretical one which might occur, it actually did several times using spring-statemachine-core-2.0.3.RELEASE.
I think this could be fixed by executing the errorAction in Actions::errorCallingAction for all kinds of Throwables.