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 “ BEA WebLogic Tuxedo Connector”

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

Configuration Guidelines

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 Administration Console Online Help.

Changing the Imported and Exported services configuration:

The changes are accepted and are implemented in the next inbound or outbound request. BEA 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 untargetting and making configuration changes, you must target the WTC service to implement the changes.

Best Practices

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 WebLogic Tuxedo Connector Administration Guide.

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 WebLogic Tuxedo Connector Administration Guide.
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 WebLogic Tuxedo Connector Administration Guide.
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 WebLogic Tuxedo Connector Administration Guide.

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 WebLogic Tuxedo Connector Administration Guide.
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 WebLogic Tuxedo Connector Administration Guide.

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

See “ Application Error Management” in the WebLogic Tuxedo Connector Programmer's Guide.
See “ System Level Debug Settings” in the WebLogic Tuxedo Connector Administration Guide.

Avoid using embedded TypedFML32 buffers inside TypedFML32 buffers. See “ Using FML with WebLogic Tuxedo Connector” in the WebLogic Tuxedo Connector Programmer's Guide.
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 WebLogic Tuxedo Connector Administration Guide.
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 WebLogic Tuxedo Connector Programmer's Guide.
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 Configuring WebLogic Server Environments.
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:
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: 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, BEA 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):

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:

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

WebLogic Server Performance and Tuning

Tuning WebLogic Tuxedo Connector

Configuration Guidelines

Best Practices