19 Tuning WebLogic Tuxedo Connector

The WebLogic Tuxedo Connector (WTC) provides interoperability between WebLogic Server applications and Tuxedo services. WTC allows WebLogic Server clients to invoke Tuxedo services and Tuxedo clients to invoke WebLogic Server Enterprise Java Beans (EJBs) in response to a service request. See "WebLogic Tuxedo Connector" in Oracle Fusion Middleware Information Roadmap for Oracle WebLogic Server.

The following sections provide information on how to get the best performance from WTC applications:

• Configuration Guidelines

• Best Practices

Configuration Guidelines

Use the following guidelines when configuring WebLogic Tuxedo Connector:

• 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 session/connection configuration (local APs, remote APs, Passwords, and Resources) after a connection/session is established.The changes accepted but are not implemented in the existing connection/session until the connection is disconnected and reconnected. See "Assign a WTC Service to a Server" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

  • 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.

Best Practices

The following section provides best practices when using WTC:

• 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 Oracle Fusion Middleware Tuxedo Connector Administration Guide 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 Oracle Fusion Middleware Tuxedo Connector Administration Guide 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 Oracle Fusion Middleware Tuxedo Connector Administration Guide 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 Oracle Fusion Middleware Tuxedo Connector Administration Guide 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 Oracle Fusion Middleware Tuxedo Connector Administration Guide 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 Oracle Fusion Middleware Tuxedo Connector Administration Guide 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 Oracle Fusion Middleware Tuxedo Connector Programmer's Guide for Oracle WebLogic Server.

  • See "System Level Debug Settings" in the Oracle Fusion Middleware Tuxedo Connector Administration Guide for Oracle WebLogic Server.

• Avoid using embedded TypedFML32 buffers inside TypedFML32 buffers. See "Using FML with WebLogic Tuxedo Connector" in the Oracle Fusion Middleware Tuxedo Connector Programmer's Guide 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 Oracle Fusion Middleware Tuxedo Connector Administration Guide 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 Oracle Fusion Middleware Tuxedo Connector Programmer's Guide 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 Oracle Fusion Middleware Configuring 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:

Table 19-1 Example of Correctly Configured Load Balancing

ResourceName	LocalAccessPoint	RemoteAccessPointList	RemoteName
service1	WDOM1	TUXDOM1	TOLOWER
service1	WDOM1	TUXDOM2	TOLOWER2

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

Table 19-2 Example of Incorrectly Configured Load Balancing

ResourceName	LocalAccessPoint	RemoteAccessPointList	RemoteName
service1	WDOM1	TUXDOM1	TOLOWER
service1	WDOM1	TUXDOM1	TOLOWER