Limitations of Migrating the Transaction Recovery Service Preparing to Migrate the Transaction Recovery Service

Managing Transactions 4-9

4.5.3.4 Managed Server Independence

Prior to WebLogic Server 10.0, when a clusters primary Managed Server was booted, but was unable to contact the Administration Server mostly because that Administration Server had not started yet, then the primary Managed Server would automatically go into MSI managed server independence mode and continue to boot up using its local configuration information. During a manual migration of the Transaction Recovery Service, this situation posed a potential risk that a backup server was still recovering TLOG data on behalf of the primary Managed Server, which could then lead to concurrent access to TLOG and potential corruption of the TLOG. To avoid risking potential TLOG corruption, there is a strictOwnershipCheck property on the JTAMigratableTargetMBean. This way, when a primary Managed Server attempts to boot up and it finds that it cannot connect to the Administration Server for the manual JTA migration policy or the Singleton Master for the automatic JTA migration policy, then it verifies its independence by checking the value of the strictOwnershipCheck, as follows: ■ True – This is the recommended setting. The primary Managed Server throws an exception and fail to boot. ■ False – The primary Managed Server skips the Transaction Recovery Service failback, then it can boot successfully. This poses the same TLOG corruption risk as in WebLogic Server 9.2 or earlier.

4.5.3.5 Limitations of Migrating the Transaction Recovery Service

When manually or automatically migrating the Transaction Recovery Service, the following limitations apply: ■ You cannot migrate the Transaction Recovery Service to a backup server from a server that is running. You must stop the server before migrating the Transactions Recovery Service. ■ The backup server does not accept new transaction work for the failed server. It only processes incomplete transactions. ■ The backup server does not process heuristic log files. ■ The backup server only processes log records written by WebLogic Server. It does not process log records written by gateway implementations, including WebLogic Tuxedo Connector. In addition to the limitations described above, the following rules also apply when WebLogic Server 10.0 or later is configured to automatically migrate the Transaction Recovery Service: ■ If the cluster also contains servers from earlier releases of WebLogic Server, the primary server and backup servers must be WebLogic Server 10.0 or later. To enforce this when automatic migration is enabled, on the Administration Console, only WebLogic Server 10.0 or later servers appear in the Candidate Servers Available list. ■ Manual service migration is supported between release 9.2 or earlier servers and release 10.0 or later servers if no migration scripts are used.

4.5.3.6 Preparing to Migrate the Transaction Recovery Service

To migrate the Transaction Recovery Service from a failed server in a cluster to another server backup server in the same cluster, the backup server must have access to the transaction log records from the failed server. Therefore, you must store default 4-10 Programming JTA for Oracle WebLogic Server persistent store data files on persistent storage available to all potential backup servers in the cluster. Consider the following: ■ A storage area network SAN is recommended. ■ If you use an NFS file system, configure the NFS server so that disk writes are not cached. ■ Regardless of the storage solution, test failover and migration. With some storage solutions, particularly some versions of NFS, file locking can be an issue. You may need to configure your storage server to handle file locks effectively or you may need to turn off file locking for the WebLogic file store. The following persistent store rules apply when manually or automatically migrating the Transaction Recovery Service: ■ The default persistent store cannot be shared by JTA and other migratable services. Other migratable services, such as JMS services, must use another custom store if they are targeted to a migratable target. ■ If post-deactivation and pre-activation scripts are specified to perform any dismounting and mounting of the default store, then the Node Manager must be configure and running on all candidate machines. The Administration Server must be available when the primary server starts up, fails over, or fails back. This is required to guarantee that the Transaction Recovery Service gets exclusive ownership to its TLOG correctly and without conflict. When the primary server starts up, the Transaction Recovery Service connects to Administration Server to get the latest information about JTA. And should failoverfailback occur, the Transaction Recovery Service saves the latest information to Administration Server. When migrating the Transaction Recovery Service from a server, you must stop the failing or failed server before actually migrating the Transaction Recovery Service. If the original server is still running, you cannot migrate the Transaction Recovery Service from it. All servers that participate in the migration must have a listen address specified in their configuration. See Configure listen addresses in the Oracle WebLogic Server Administration Console Help. Important: NFS storage may not fully protect transactional data, as it may be configured to silently buffer synchronous write requests in volatile memory. If a file store Directory is located on an NFS mount, and the file store’s Synchronous Write Policy is anything other than Disabled , check your NFS implementation and configuration to make sure that it is configured to support synchronous writes. A Disabled synchronous write policy does not perform synchronous writes, but, as a consequence, is generally not transactionally safe. You may detect undesirable buffering of synchronous write requests by observing high persistent message or transaction throughput that exceeds the physical capabilities of your storage device. On the NFS server, check the synchronous write setting of the exported NFS directory hosting your File Store. A SAN based file store, or a JDBC store, may provide an easier solution for safe centralized storage. See File Locking and NFS in Performance and Tuning for Oracle WebLogic Server. Managing Transactions 4-11

4.5.3.7 Constraining Servers to Which the Transaction Recovery Service Can Migrate