This implementation of tpMethodReq is aware of the domain
configuration files which correlate services with local and
remote domains. It gets the table of services from a static
WTCService method, and uses that to look up the proper local
and then remote domain to which to route this object. Once
the proper remote domain has been chosen, it does the
tpMethodReq to the remote domain, returning an object
that can be used in subsequent calls to tpgetrply.
This implementation does not yet handle the case of blocking replies
with the TPGETANY flag. The problem is that the reply may span more than
one remote domain, and the only way to handle that is either with threads
at this layer or by getting support from the lower layer for a multi-remote
domain reply architecture, which I favor. Hence, this implementation is
only in order so that we can get our feet wet, and smoke out some of the
other WLS integration issues that are sure to arise.
cd - same as ApplicationToMonitorInterface interface
flags - same as ApplicationToMonitorInterface interface
same as ApplicationToMonitorInterface interface
TPException - Upon failure tpgetrply throws TPException to indicate the
error condition. tperrno in TPException will be set to one of the following
TPEINVAL: Invalid arguments were given. For example: cd or
flags are invalid.
TPEOTYPE: The type and sub-type of the reply are not known to the
caller. If the reply was to be received on behalf of the caller's
current transaction, then the transaction is marked abort-only
as the reply is discarded.
TPEBADDESC: cd points to an invalid descriptor.
TPETIME: A timeout occurred. If the caller is in transaction mode,
then a transaction timeout occurred and the transaction is marked
abort-only. Otherwise, a blocking timeout occurred and neither
TPNOBLOCK nor TPNOTIME were specified. If a transaction timeout
occurred, then with one exception, any attempts to send new requests
or receive outstanding replies will fail with TPETIME until the
transaction has been aborted. The exception is a request that does
not block, expects no reply and is not sent on behalf of the
caller's transaction - tpacall with TPNOTRAN,
TPNOBLOCK and TPNOREPLY set.
TPEBLOCK: A blocking condition exists and TPNOBLOCK was specified.
TPEPROTO: tpgetrply was called improperly.
TPESYSTEM: A BEA Tuxedo system error has occurred. The exact nature
of the error is written to a log file.
TPEOS: An operating system error has occurred. If a message queue on
a remote location is filled, TPEOS may be returned.
TPReplyException - If there is a service failure (TPESVCFAIL or
TPSVCERROR) in which case the exception will also have reply
data from the service. However, unlike the tpcall case, this
execption may also be thrown in any of the above TPException cases as well,
so that specific TPException return codes can be matched with the
request object returned from tpacall. If TPReplyException is thrown
then it is on behalf of an outstanding request and that request is considered
to have completed with a failure.
Excluded in public API Reference.
need to override superclass' implementation to do correct