The atomic scope was designed to handle Atomicity, Consistency,
Isolation, and Durability (ACID) compliant operations that must either all succeed or
all fail as a group. This is a classic database transaction style. It is designed to carry
an orchestration from one stable state to another.
A transaction represents an atomic unit of work. Either all modifications within a transaction are performed, or none of the modifications are performed.
When committed, a transaction must preserve the integrity of the data within the system. If a transaction performs a data modification on a database that was internally consistent before the transaction started, the database must still be internally consistent when the transaction is committed. Ensuring this property is largely the responsibility of the application developer.
Modifications made by concurrent transactions must be isolated from the modifications made by other concurrent transactions. Isolated transactions that run concurrently perform modifications that preserve internal database consistency exactly as they would if the transactions were run serially.
After a transaction is committed, all modifications are permanently in place in the system by default. The modifications persist even if a system failure occurs.
If you absolutely must call a non-Serializable class, and can only do
it in an atomic scope, try to combine this with other operations to make the most of
the trip to the message box; like a send shape as shown in the following figure:
No comments:
Post a Comment