Adabas Transaction Manager applies distributed transaction integrity as
soon as the first ET of a series is encountered.
This suggests the subsequent ET commands of the
series are not needed but that is incorrect. Well-formed distributed
transaction programming is still necessary and enforced. Here’s why:
| 1. | Modify data in Adabas database A |
| 2. | Modify data in Adabas database B |
| 3. | Issue ET command to Adabas database A
|
| 4. | Issue BT command to Adabas database B
|
In the example above, the application is breaking the rules of distributed transaction processing by adopting unsafe behavior. The rules of DTP stipulate the modifications for all databases in a distributed transaction are all applied or all undone; it is not legal to have a mixture of some applied and some undone.
In this situation Adabas Transaction Manager throws an error when the
BT in point 4 above is encountered (response 240
sub-code 496). Here’s another example, just a little more complicated:
| 1. | Modify data in Adabas database A |
| 2. | Modify data in Adabas database B |
| 3. | Issue ET command to Adabas database A
|
| 4. | Modify data in any database (A or B or another)
|
In this example, the application issues only one
ET command, it does not issue an
ET command to the second database. Then it goes on
to do other work – in this case to start doing modifications in a new
transaction. This logic is breaking the rules of distributed transaction
processing with unsafe behavior too. In this situation Adabas Transaction
Manager throws an error when the modification in point 4 above is encountered
(response 240 sub-code 496). Some people find it difficult to understand why
this example breaks the rules so consider what might happen without Adabas
Transaction Manager being used:
| 1. | Modify data in Adabas database A |
| 2. | Modify data in Adabas database B |
| 3. | Issue ET command to Adabas database A
|
| 4. | Modify more data in Adabas database B |
| 5. | Issue ET command to Adabas database
B
|
This is really not a good situation when Adabas Transaction Manager is not present. Here is what has happened…
| 1. | The modification to Adabas A is applied. |
| 2. | The first modification to Adabas B is undone. |
| 3. | The second modification to Adabas B is applied…
|
The only way to be sure distributed transactions are executed correctly in your business systems is to make sure there is no room for doubt by
adopting Adabas Transaction Manager
and
allowing it to enforce well-formed distributed transaction processing behavior, as it does by default.
