A proper SPINCOUNT indicates a server can hold the BB lock via user level method at most time. It can significantly improve the performance in the scenarios where BB lock conflict is heavy. The typical scenario is the transactional application using Tuxedo XA mechanism. So it is recommended to enable this feature on the Oracle Exalogic by default in a Tuxedo application unless the CPU is not enough.

A process or thread locks the bulletin board through user level method or system level method. Because system level method is a costly operation, it is efficient to set a proper number of lock spins so that most lock attempts are achieved through user level method.

A process on a uniprocessor system should not spin. A SPINCOUNT value of 1 is appropriate for uniprocessors. On multiprocessors, the value of the SPINCOUNT parameter is application- and system-dependent. Self-Tuning Lock Mechanism can figure out the proper SPINCOUNT automatically.

SHMQ helps you to gain higher performance in the native Tuxedo application by reducing unnecessary message copy. It can be considered to enable this feature when one or more cases are met in the following list:

• big request/reply message
• simple/little service

  If the service routine itself does not spend too much time, the performance should be improved with this feature by reducing the message copy.

• IPC resource

  Not only more shared memory, but also extra semaphores are necessary if this features enabled. It is recommended to check the minimum IPC resources via tmloacf -c before using this feature.

The default value is good enough for almost all scenarios. But, you require adjust the value of SHMQMAXMEM in UBBCONFIG if the message size is greater than 32 Kbytes, the detail is as follow:

• SHMQMAXMEM = (Recommend_value * Message_size) / 32

• Recommend_value: The value returned by tmloadcf -c
• Message_size: The buffer size for one message (Kbytes)

Given a specific shared memory used by the SHMQ, the Tuxedo would divide it into several parts for different sized buffers. In general, the bigger the buffer size is, the less the total entries for this kind of buffer are. If some sized buffer is too much, the Tuxedo will convert to use local memory although the whole shared memory for SHMQ is not full.

In this release, there are two new MIB fields, TA_SHMQSTAT and TA_MSG_SHMQNUM, which are used to get the detailed information about shared memory usage. For more details about TA_SHMQSTAT and TA_MSG_SHMQNUM, see TM_MIB(5) in Section 5 - File Formats, Data Descriptions, MIBs, and System Processes Reference.

It is a new flag of TPNOCOPY in tpcall() for using SHMQ message. A typical Tuxedo user case of zero-copy messaging:

1. Client gets request SHMMSG buffer by tpalloc()
2. Client sends the request to server's request SHMQ by tpcall(), and waits for reply
3. Server receives the request from its request SHMQ, processes the request
4. Server use the same SHMMSG buffer for reply
5. Server sends the reply to client's reply SHMQ by tpreturn()
6. Client receives the reply from its reply SHMQ

Zero-copy messaging is an ideal circumstance, with the pre-condition that sender and receiver cannot access the shared buffer at the same time. In the real world, to guarantee safe memory access, sender needs to do one copy and send the copy instead of original SHMMSG. However, to gain advanced performance, new flag TPNOCOPY is provided for tpcall() to avoid the copy cost. If application chooses to use this flag, it must take the responsibility to make sure no access to the SHMMSG buffer after tpcall() fails, except for tpfree().

When TPNOCOPY is set for tpcall() flags and the send buffer is SHMMSG buffer, no safe copy will be done during message sending. After tpcall() succeeds, sender application has full access of the send buffer as normal. But if tpcall() fails in any circumstance, sender application cannot access the send buffer any more. In this case the recommended action is tpfree() the buffer, and this is the only safe operation on the buffer.

TPNOCOPY cannot be set for tpacall(), or tpacall() will fail with tperrno set to TPEINVAL.

In general, the tuxedo native request/reply messages will be transferred using shared memory queue (SHMQ) if the feature is available. But the IPC queue is used instead in the following cases:

• Encoded Tuxedo message
• Stateful CORBA object
• Tuxedo message associated with digital signature and encryption

  For example, tpseal() or tpsign() marks the Tuxedo message for encryption or digital signature.

• Tuxedo messages out from a server specified with BUFTYPECONV
• Tuxedo FML32 typed message with any field typed pointer
• Tuxedo FML32 typed message with any field typed embedded FML32

If a Tuxedo application is running on the Oracle RAC, you may want to take advantage of non-singleton database service, such as load balance, service failover, and so on. Tuxedo groups can use RAC non-singleton service by enabling this feature. Given that the business may involve multiple groups, it is better to also enable Common XID and XA Transaction Affinity to achieve good performance.

A typical UBB configuration is as follows.

Listing UBB Configuration

*RESROUCES
MODEL         SHM
OPTIONS       XPP
...
 
*MACHINES
"mach1"      LMID=L1
...
 
*GROUPS
GRP1        LMID=L1 GRPNO=10 TMSNAME="TMSORA1"
            OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux3+ACC= 
P/scott/tiger +SesTM=120"
GRP2        LMID=L1 GRPNO=20 TMSNAME="TMSORA2"
            OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux3+ACC= 
P/scott/tiger +SesTM=120"
 
*SERVERS
server1     SRVGRP=GRP1 SRVID=10 MIN=4
server2     SRVGRP=GRP2 SRVID=10 MIN=4
...

GRP1 and GRP2 use the same net service orcl.tux3 to connect the resource manager; orcl.tux3 is configured to database service tux3, which both RAC instance1 and instance2 support. Server1 offers Tuxedo service svc1 and server2 offers Tuxedo service svc2. The transactional business A calls svc1 and then svc2, and so involves both server1 and server2. Because orcl.tux3 is non-singleton database service, server1 copies associate with either instance1 or instance2, so do server2 copies.

SGMB can ensure business working well and ensure that business A transactions are distributed evenly on instance1 and instanc2.

Given that both Common XID and XA Transaction Affinity are enabled, all business A transactions become one-phase commit.

• Groups with multiple resource managers are not supported.
• A transaction fails if more than 16 instances are involved in a single group.
• Partial One Phase Read-Only Optimization for RAC does not work in a transaction if the preferred reserved group is a multi-branch group. If GWTDOMAIN is not the coordinator, the preferred reserved group is the coordinator group; otherwise, the preferred reserved group is the participated group coming next in the coordinator domain.
• Multi-threaded servers do not provide instance information via MIB; however, SGMB still performs well on server-dispatched threads.

• Scenario A
  
• Scenario B
  
• Scenario C
  
• Scenario D
  

• Groups with multiple resource managers are not supported.
• Multi-threaded servers do not provide instance information via MIB; however, common XID still performs well on server-dispatched threads.
• In two-phase commit scenarios, GWTDOMAIN is always involved to do prepare and/or commit

It is recommended to enable this feature when Tuxedo server has multiple instances running on different Oracle RAC instances via the same Oracle Database service.

In the event that XA Transaction Affinity is enabled, there is no need to utilize the rule of Oracle RAC routing specified by the environment variable TUXRACGROUPS, and this rule will be disabled.

The following picture illustrates the changes that will be made when XA Transaction Affinity is enabled.

Figure 3-1 XA Transaction Affinity Enablement

• Groups with multiple resource managers are not supported.
• The max number of affinity context (database name+instance name+service name) in one transaction is 16.
• XA Transaction Affinity does not support multi-server single queue, multi-threaded server, or cross-domain services.

To benefit from Oracle FAN (Fast Application Notification), it is recommended to enable this feature anytime when Tuxedo works with Oracle RAC.

Besides UBBCONFIG, set Oracle Database properly for the following configurations:

• ONS (Oracle Notification System)

  This feature depends on ONS (Oracle Notification System) to access FAN events. ONS daemon must be enabled on Oracle Database server side and client side if Tuxedo is taken as a native ONS client. It is recommended that Tuxedo works in remote mode.

  The ONS daemon configuration file is located in $ORACLE_HOME/opmn/conf/ons.config. This file tells the ONS daemon how to behave. Configuration information within ons.config is defined in simple name and value pairs.

  After configuring ONS, you can start it with onsctl command. Make sure that ONS daemon is running all the time.

  Note:

  On Oracle Database client side, if the Oracle version is lower than 12.1.0.1.0, ONS daemon must be enabled.
• TAF (Transparent Application Failover)

  TAF is recommended when Oracle Tuxedo non-XA server works with Oracle RAC Fast Application Notification (FAN).

  TAF (Transparent Application Failover) is an Oracle Database client-side feature that allows clients to reconnect surviving database instances automatically in the event of database instance failure.

  • If TAF is configured, Oracle client will be responsible for re-establishing the new connection from Oracle Tuxedo to Oracle Database server.
  • If TAF is not configured, Oracle Tuxedo non-XA server will not do the re-establishment and so this feature will not work.

To monitor FAN event for the instance associated with the specific non-XA application server, $TUXDIR/lib/tuxociucb.so.1.0 should be deployed in $ORACLE_HOME/lib, and the name of this binary must be specified in ORA_OCI_UCBPKG environment variable.

To support TAF, follow the rules as below:

• For OCI application, create OCI environment in OCI_THREADED mode.
• For Pro*C application, run pre-compilation with threads=yes and use EXEC SQL ENABLE THREADS before creating the first executable embedded SQL statement.

-L option in servopts must be used for a non-XA server to indicate that the server will connect to the Oracle Database. Since the ECID is enabled when -L is specified, a new option -F is introduced into servopts to close ECID. The usage is -F noECID. The example is below.

Listing Example for -L Option

*SERVERS
server1
SRVGRP=GRP1 SRVID=1 ClOPT="-L libclntsh.so -F noECID"

• Groups with multiple resource managers are not supported.
• If the customized server is going to use OCI to connect to Oracle Database, OCI_NO_UCB should not be set at OCI initialization time.

To benefit from Oracle FAN (Fast Application Notification), it is recommended to enable this feature anytime when Tuxedo works with Oracle RAC.

Configure UBBCONFIG and Oracle Database the same as Failover/Failback across Database Instances, and set LBA (Load Balance Advisory) as follows.

• LBA (Load Balance Advisory)

  Based on Oracle Database load balance advisory, Tuxedo can distribute service request across Tuxedo application server that is connected to the same Oracle Database service. To enable LBA and publication of FAN load balancing events, the service-level goal for runtime connection load balancing must be specified in Oracle Database service definition. You can use -B option to specify the goal via srvctl when creating or modifying the service.

See Recommendation for Non-XA Server for the recommendation.

• Groups with multiple resource managers are not supported.
• If the customized server is going to use OCI to connect to Oracle Database, OCI_NO_UCB should not be set at OCI initialization time.
• Load balance based on Oracle RAC LBA does not support multi-server single queue, multi-threaded server, or cross-domain services.