Transaction

A Flow's transaction is managed by the transaction manager.

A transaction manager controlls to run the Flow once.
Although other Flows such as SubFlow, Error Processing Flow, NextFlow will run during a Flow is running, the series of Flows are controlled by the transaction manager.
(But, the Flow executed by the FlowInvoker Component isn't included in a transaction.)

Stack transactions

When you run a component that uses transaction, you can add transactions to the transaction manager.
For example, transaction is used in the below components.

Component	Commit	Roll back
RDBPut	Release commit to RDB	Release roll back to RDB
FileGet	Delete the imported files	Do nothing
POP3	Delete the imported mail	Do nothing

Basically, the transactions are added into the transaction manager in order, but there are 2 exceptions.

Priority is set.

You can set a priority for transactions.
If a priority has been set, transactions won't be added to the last, but will be inserted to the appropriate place according to the priority.

Now, only the priority of the transactions related to RDB can be set as the highest.

The same transctions can't be stacked multiple times

If multiple components will add the same transactions to the transaction manager, the second one or the later ones will be ignored.

For example, to add the RDB Components with the same connections are the same transactions.
Therefore, although there are multiple RDB Components configured in a series of Flows, there is only one transaction can be added into the transaction manager for the RDB.

Commit (or roll back) a transaction manager

You can decide the time to commit a transaction manager by setting the "Transactionized" property of a Start Component.

Transactionized	Committing time
Yes	After a Flow has finished, you can commit or roll back it according to the End Component's "Transaction" property
No	Once a component is executed, it will be committed.

Namely, if a Flow is transactionized, the Flow will commit the all transactions added by the components together after the Flow has finished. But if the Flow isn't transactionized, its component will commit the transaction once it add the transaction.

For example, if an RDB Component will insert millions of records one by one in loop, the times of releasing commit to RDB will be decided by the "Transactionized" property, so the performances will be very different.
(Certainly, it's different in when to commit to RDB.)

You can select to commit or roll back the transaction manager by using the End Component of the transactionized Flow. But in the untransactionized Flow, it will be rolled back only when an error happens.

SubFlow and transaction

No matter how the "Transactionized" property has been set, if a caller Flow is transactionized, its SubFlow is also transactionized.

If the caller Flow isn't transactionized, it's possible that its SubFlow is transactionized.

Error Processing Flow and its transaction

When a caller Flow is transactionized, the transaction manager will be passed to the Error Processing Flow directly without being done anything.
Then, no matter how the "Transactionized" property of the Error Processing Flow's Start Component has been set, the Error Processing Flow will also be transactionized.
Namely, the Error Processing Flow is a part of the transaction of the transactionized Flow, so you can select whether to commit or roll back it when it has finished.

If a caller Flow isn't transactionized, the transaction manager will be passed to the Error Processing Flow after it has been rolled back.
You can decide how to control the Error Processing Flow's own transaction according to the Start Component's "Transaction" property.

NextFlow's transaction

Usually, there are 2 choices in the End Component's "transaction" property, which are "Commit" and "Roll back". But for the NextFlow Component, there is the third choice in the property--"Do nothing".
By selecting "Do nothing", the transaction manager can inherit the transaction for the next Flow without doing anything.

2-phase committing

By selecting "XA supported" for the RDB connection settings, you can do the 2-phase committing.
Inside the connection that supports XA, multiple RDB transactions will be merged into one, then prepare will be released to the all RDBs, and so commit will be.

Now, the DBMSs that supports 2-phase committing are as below.

• Oracle9i or later (only thin driver)
• SQLServer2000 or later
• DB2 9 or later (only type2 driver)
• MySQL 5.0 or later
• PostgreSQL8.2 or later

Extended transaction and recovery

If a transaction is an extended transaction, it will recover the error that happens in the system.
The below are the 2 "system errors".

• The Flow Service itself finished abnormally.
• The error in the DBMS connected to the Flow Service, or the connection with DBMS is blocked by a network failure.

The errors in a common running Flow are not included in the "system error".
(If the errors happen, and they are rolled back by the transaction manager, it's not necessaty to recover them as above.)

In an extended transaction, if an error of an RDB is detected while the transaction is being executed (For example, prepare succeeded but commit failed etc), it will be recovered according to the FSMC's settings.

Moreover, if the Flow Service finished abnormally while the transactiong is running, it will be recovered if the system is restarted.

The detail about the extended transaction has been written in "Guide for SDK component developer ".
Please refer to the above content and "SDK component developer guide" for more information about the specification.