The following bugs have been fixed in XMLink 2.50.00.07
|
Bug
Number |
Description |
|
36806 |
BLOCKTIME
support added for Tuxedo 6 since customers may want to use BLOCKTIME, in
addition to (or instead of SVCTIMEOUT) to allow clients to recover from
unforseen circumstances. Note
that we do not use blocking calls for Tuxedo 6, because while a call is being
blocked, we cannot make other TAPI calls from other threads. This is because the Tuxedo 6 libraries are
not thread safe. |
|
36807 |
Added
support for tpurcode(). User return code cna be used to return Tuxedo error
codes from the server. This is needed because the server is used as a proxy
for the client, in order to invoke services in a transactional context for
Tuxedo 6. In
addition to support for Tuxedo.tpurcode(), Interaction.getWarnings() and
Interaction.clearWarnings() can be used. These methods are part of the CCI
interface, but were previously unused by our product. Now, whenever a
non-zero user code is returned, a TuxedoReturnCodeWarning is created and
added to the head of a linked list associated with the Interaction.
TuxedoReturnCodeWarning extends ResourceWarning, and these can be chained.
ResourceWarning implements setLinkedException() and getLinkedException(). Note
that no Exception is thrown. They are simply added to the chain.
Interaction.getWarnings() will return the head of the chain, which is the
most recent ResourceWarning generated. It will return null if there are none.
It can be reset to null by Interaction.clearWarnings(). The warnings are also
cleared if you call Interaction.close(). TuxedoReturnCodeWarning implements
getReturnCode(), which returns a long, and getInteractionSpec(), which
returns the InteractionSpec instance associated with the service call that
generated the return code. toString() can be used to generate a String of the
form "<function-name> returned <code>." Note that the a
TuxedoReturnCodeWarning will be generated for a non-zero user return code,
regardless of whether TPSUCCESS or TPFAIL is returned by the service as well.
Thus Interaction.getWarings() can be used directly after
Interaction.execute() is called, as well as in an exception handler block. |