Filter
Top Products
6. “Routing by user ID” on page 644
7. “Dealing with an abend on the target region” on page 644
8. “Some processing considerations” on page 645
9. “Parameters passed to the distributed routing program” on page 645
10. “Naming your distributed routing program” on page 656
11. “Distributed transaction routing sample programs” on page 657
Differences between the distributed and dynamic routing interfaces
This section discusses some significant ways in which the distributed routing
interface differs from the dynamic routing interface. If you have previously written a
dynamic routing program, and are about to write a distributed routing program, bear
in mind that:
1. The dynamic routing program is only invoked if the resource (the transaction or
program) is defined as DYNAMIC(YES). The distributed routing program, on the
other hand, is invoked (for BTS activities that are run asynchronously, eligible
method requests for enterprise beans and CORBA stateless objects, and
eligible non-terminal-related START requests) even if the associated transaction
is defined as DYNAMIC(NO)—though it cannot route the request. What this
means is that the distributed routing program is better able to monitor the effect
of statically-routed requests on the relative workloads of the target regions.
2. Because the dynamic routing program uses the hierarchical “hub” routing
model—one routing program controls access to resources on several target
regions—the routing program that is invoked at termination of a routed request
is the same program that was invoked for route selection.
The distributed routing program, on the other hand, uses the distributed model,
which is a peer-to-peer system; the routing program itself is distributed. The
routing program that is invoked at initiation, termination, or abend of a routed
transaction is not the same program that was invoked for route selection—it is
the routing program on the target region.
Because the dynamic routing program is invoked only on the routing region, the
order of its invocations is strictly defined:
a. Route selection or notification
b. Route selection error (if appropriate, and possibly repeated)
c. Transaction termination or abend (if requested).
For a single request, the user area passed to each invocation of the dynamic
routing program is the same piece of storage; any modifications made to the
user area on one invocation are retained and passed to the next invocation.
The distributed routing program, on the other hand, may be invoked on the
target region as well as on the routing region; because of this, the order of its
invocations is less strictly defined. For example, the final invocation on the
routing region (for “routing attempt complete”) may occur before or after the first
invocation on the target region (for “transaction initiation”). To cope with this
uncertainty, the user area passed to the distributed routing program on its first
invocation on the target region is a copy of the user area on the routing region.
This means that any modifications to the user area made on the target region
have no effect on the user area in the routing region. For more details, see the
description of the DYRUSER field in “Parameters passed to the distributed
routing program” on page 645.
624 Customization Guide