Page History
| Div | ||
|---|---|---|
| ||
|
...
...
...
...
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:
| Multiexcerpt include | ||||
|---|---|---|---|---|
|
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 | ||||
|---|---|---|---|---|
| ||||
<your path>\RUNTIME_2018.2\uml\session_committed_after_exception.xml |
| Note | ||
|---|---|---|
| ||
Updating to Runtime 2018.2 is strongly recommended. |
Overview
Content Tools