• You may have more than one WTC Service in your configuration.

• You can only target one WTC Service to a server instance.

• WTC does not support connection pooling. WTC multiplexes requests though a single physical connection.

• Configuration changes implemented as follows:

  • Changing the session/connection configuration (local APs, remote APs, Passwords, and Resources) before a connection/session is established. The changes are accepted and are implemented in the new session/connection.

  • Changing the Imported and Exported services configuration. The changes are accepted and are implemented in the next inbound or outbound request. Oracle does not recommend this practice as it can leave in-flight requests in an unknown state.

  • Changing the tBridge configuration. Any change in a deployed WTC service causes an exception. You must untarget the WTC service before making any tBridge configuration changes. After untargeting and making configuration changes, you must target the WTC service to implement the changes.

• When configuring the connection policy, use ON_STARTUP and INCOMING_ONLY. ON_STARTUP and INCOMING_ONLY always paired. For example: If a WTC remote access point is configured with ON_STARTUP, the DM_TDOMAIN section of the Tuxedo domain configuration must be configured with the remote access point as INCOMING_ONLY. In this case, WTC always acts as the session initiator. See Configuring the Connections Between Access Points in the Administering WebLogic Tuxedo Connector for Oracle WebLogic Server.

• Avoid using connection policy ON_DEMAND. The preferred connection policy is ON_STARTUP and INCOMING_ONLY. This reduces the chance of service request failure due to the routing semantics of ON_DEMAND. See Configuring the Connections Between Access Points in the Administering WebLogic Tuxedo Connector for Oracle WebLogic Server.

• Consider using the following WTC features: Link Level Failover, Service Level failover and load balancing when designing your application. See Configuring Failover and Failback in the Administering WebLogic Tuxedo Connector for Oracle WebLogic Server.

• Consider using WebLogic Server clusters to provide additional load balancing and failover. To use WTC in a WebLogic Server cluster:

  • Configure a WTC instance on all the nodes of the WebLogic Server cluster.

  • Each WTC instance in each cluster node must have the same configuration.

  See How to Manage WebLogic Tuxedo Connector in a Clustered Environment in the Administering WebLogic Tuxedo Connector for Oracle WebLogic Server.

• If your WTC to Tuxedo connection uses the internet, use the following security settings:

  • Set the value of Security to DM_PW. See Authentication of Remote Access Points in the Administering WebLogic Tuxedo Connector for Oracle WebLogic Server.

  • Enable Link-level encryption and set the min-encrypt-bits parameter to 40 and the max-encrypt-bits to 128. See Link-Level Encryption in the Administering WebLogic Tuxedo Connector for Oracle WebLogic Server.

• Your application logic should provide mechanisms to manage and interpret error conditions in your applications.

  • See Application Error Management in the Developing Oracle WebLogic Tuxedo Connector Applications for Oracle WebLogic Server.

  • See System Level Debug Settings in the Administering WebLogic Tuxedo Connector for Oracle WebLogic Server.

• Avoid using embedded TypedFML32 buffers inside TypedFML32 buffers. See Using FML with WebLogic Tuxedo Connector in the Developing Oracle WebLogic Tuxedo Connector Applications for Oracle WebLogic Server.

• If your application handles heavy loads, consider configuring more remote Tuxedo access points and let WTC load balance the work load among the access points. See Configuring Failover and Failback in the Administering WebLogic Tuxedo Connector for Oracle WebLogic Server.

• When using transactional applications, try to make the remote services involved in the same transaction available from the same remote access point. See WebLogic Tuxedo Connector JATMI Transactions in the Developing Oracle WebLogic Tuxedo Connector Applications for Oracle WebLogic Server.

• The number of client threads available when dispatching services from the gateway may limit the number of concurrent services running. There is no WebLogic Tuxedo Connector attribute to increase the number of available threads. Use a reasonable thread model when invoking service. See Thread Management and Using Work Managers to Optimize Scheduled Work in Administering Server Environments for Oracle WebLogic Server.

• WebLogic Server Releases 9.2 and higher provide improved routing algorithms which enhance transaction performance. Specifically, performance is improved when there are more than one Tuxedo service requests involved in a 2 phase commit (2PC) transaction. If your application does only single service request to the Tuxedo domain, you can disable this feature by setting the following WebLogic Server command line parameter:

  -Dweblogic.wtc.xaAffinity=false

• Call the constructor TypedFML32 using the maximum number of objects in the buffer. Even if the maximum number is difficult to predict, providing a reasonable number improves performance. You approximate the maximum number by multiplying the number of fields by 1.33.

  Note:

  This performance tip does not apply to TypedFML buffer type.

  For example:

  If there are 50 fields in a TypedFML32 buffer type then the maximum number is 63. Calling the constructor TypedFML32(63, 50) performs better than TypedFML32().

  If there are 50 fields in a TypedFML32 buffer type and each can have maximum 10 occurrences, then call the constructor TypedFML32(625, 50) will give better performance than TypedFML32().

• When configuring Tuxedo applications that act as servers interoperating with WTC clients, take into account of parallelism that may be achieved by carefully configuring different servers on different Tuxedo machines.

• Be aware of the possibility of database access deadlock in Tuxedo applications. You can avoid deadlock through careful Tuxedo application configuration.

• If your are using WTC load balancing or service level failover, Oracle recommends that you do not disable WTC transaction affinity.

• For load balancing outbound requests, configure the imported service with multiple entries using a different key. The imported service uses composite key to determine each record's uniqueness. The composite key is compose of "the service name + the local access point + the primary route in the remote access point list".

  The following is an example of how to correctly configure load balancing requests for service1 between TDomainSession(WDOM1,TUXDOM1) and TDomainSession(WDOM1,TUXDOM2):

The following is an example an incorrectly configured load balancing requests. The following configuration results in the same composite key for service1: