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:

    1. Route selection or notification
    2. Route selection error (if appropriate, and possibly repeated)
    3. 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.

  3. The distributed routing program is invoked at more points than the dynamic routing program. Figure 48 shows the points at which the distributed routing program is invoked, and the region on which each invocation occurs.
  4. Unlike the dynamic routing program, the distributed routing program cannot:

    These restrictions are documented more fully in the descriptions of the relevant fields in the DFHDYPDS communications area.

Related tasks
Routing BTS activities
Routing method requests for enterprise beans and CORBA stateless objects
Routing non-terminal-related START requests
Naming your distributed routing program
Rewriting user-replaceable programs
Assembling and link-editing user-replaceable programs
Related reference
Parameters passed to the distributed routing program
Distributed transaction routing sample programs
[[ Contents Previous Page | Next Page Index ]]