Bug: Session Commit on Exception

The xUML Runtime works with the concept of sessions as described on https://doc.scheer-pas.com/bridge/?contextKey=xuml-runtime-transaction-concepts&version=latest. Sessions are equivalent to units of work, that can be committed or rolled back depending on the status at the end of the session.

The following action types are affected on commit / roll back:

Action TypeExampledatabase accessinsertion or deletion of database recordspersistent state handlingcreation of a persistent state object, sending of a persistent state signal, sending of conversation signalsJMS activitiessending or receiving of JMS messages with acknowledge mode transactedPOP3 activitiesdeletion of mails from POP3 server

With Runtime 2018.2 , we fixed a serious bug that led to a session commit although an exception had occurred and the session should have been rolled back. If an exception occurred in an action that was followed directly by a decision node, the exception was logged and the activity was aborted, but the xUML Runtime assumed nevertheless that execution has been fine and committed the session.

	This is the behavior, if no exception occurs and everything works fine. The session is processed until its end and then committed.
	This is the behavior in case of exception before Runtime 2018.2. The session aborted, but nevertheless committed. That resulted in SQL, persistent state, JMS, and POP3 changes being committed instead of rolled back in case of error. Additionally, no error handlers have been invoked either.
	This is the behavior in case of exception as of RUNTIME 2018.2. The session is aborted and rolled back.

You can test this behavior with the attached xUML project. It contains a REST service with an SQLite backend. Simply deploy the service to your Bridge instance and test it with the REST Test Tool.

Related Content