Bug: Session Commit on Exception
The E2E xUML Runtime works with the concept of sessions as described on xUML Runtime Transaction Concepts. 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 Type | Example |
|---|---|
| database access | insertion or deletion of database records |
| persistent state handling | creation of a persistent state object, sending of a persistent state signal, sending of conversation signals |
| JMS activities | sending or receiving of JMS messages with acknowledge mode transacted |
| POP3 activities | deletion 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 E2E 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.
Example File (Builder project Add-ons/EDI):
 | <your path>\RUNTIME_2018.2\uml\session_committed_after_exception.xml |
Updating to Runtime 2018.2 is strongly recommended.
Related Pages: