|
|
The following sections provide configuration tasks related to transactions:
The Administration Console provides the interface used to configure features of WebLogic Server, including WebLogic JTA. The configuration process involves specifying values for attributes. These attributes define the transaction environment, including the following:
You should also be familiar with the administration of J2EE components that can participate in transactions, such as EJBs, JDBC data sources, and JMS.
| Note: | You can also use the WebLogic Scripting Tool (WLST; see WebLogic Scripting Tool) or JMX (see Developing Custom Management Utilities with JMX) to configure transaction-related settings. |
Once you configure WebLogic JTA and any transaction participants, the system can manage transactions using the JTA API and the WebLogic JTA extensions. Note the following:
If you have resources that you may occasionally undeploy and redeploy such as a JDBC data source module packaged with an application, you can minimize the risk of abandoned transactions because of an unregistered resource by setting the Unregistered Resource Grace Period for the domain. The grace period is the number of seconds that the transaction manager waits for transactions to complete before unregistering a resource.
During the specified grace period, the unregisterResource call will block until the call can return, and no new transactions are started for the associated resource. If the number of outstanding transactions for the resource goes to 0, the unregisterResource call returns immediately.
At the end of the grace period, if there are still outstanding transactions associated with the resource, the unregisterResource call returns and a log message is written on the server on which the resource was previously registered.
By default, if an XA resource that is participating in a global transaction fails to respond to an XA call from the WebLogic Server transaction manager, WebLogic Server flags the resource as unhealthy and unavailable, and blocks any further calls to the resource in an effort to preserve resource threads. The failure can be caused by either an unhealthy transaction or an unhealthy resource—there is no distinction between the two causes. In both cases, the resource is marked as unhealthy.
To mitigate this limitation, WebLogic Server provides the configuration attributes listed in Table 3-1:
|
Enables or disables resource health monitoring for the JDBC data source. This attribute only applies to data sources that use an XA JDBC driver for database connections. It is ignored if a non-XA JDBC driver is used.
If set to
true, resource health monitoring is enabled. If an XA resource fails to respond to an XA call within the period specified in the MaxXACallMillis attribute, WebLogic Server marks the data source as unhealthy and blocks any further calls to the resource.
You can set the Resource Health Monitoring attribute for a JDBC data source on the
JDBC Data Source: Configuration: Connection Pool tab in the Administration Console.
|
||
Except for Resource Health Monitoring for a JDBC data source, you set these attributes directly in the config.xml file when the domain is inactive. These attributes are not available in the Administration Console. The following example shows an excerpt of a configuration file with these attributes:
...
<JTA
MaxUniqueNameStatistics="5"
TimeoutSeconds="300"
RecoveryThresholdMillis="150000"/>
MaxResourceUnavailableMillis="900000"
MaxResourceRequestOnServer="60"
MaxXACallMillis="180000"
For a transaction manager to manage distributed transactions, the transaction manager must be able to communicate with all participating resources to prepare and then commit or rollback the transactions. This applies to cases when your WebLogic domain acts as the transaction manager or a transaction participant (resource) in a distributed transaction. The following sections describe how to configure your domain to enable inter-domain transactions.
The following sections provide information on how to configure domains for inter-domain transactions:
Please note the following limitations for inter-domain transactions:
| Note: | BEA recommends that you use an XA driver instead of a non-XA driver (with Emulate Two-Phase Commit) in global transactions. There are risks involved with using a non-XA driver in a global transaction. See Limitations and Risks When Emulating Two-Phase Commit Using a Non-XA Driver in Configuring and Managing WebLogic JDBC. |
You must correctly configure compatible communication channels using either Cross Domain Security or Security Interoperability Mode for all participating domains in global transactions.
Keep all the domains used by your process symmetric with respect to Cross Domain Security configuration and Security Interoperability Mode. Because both settings are set at the domain level, it is possible for a domain to be in a mixed mode, meaning the domain has both Cross Domain Security and Security Interoperability Mode set.
The following sections provide more information on configuring communication channels for global transactions:
Use the following table to determine the type of communication channel configuration required for inter-domain transactions:
| Note: | When Security Interoperability Mode is set to performance, you are not required to set domain trust between the domains. |
There is a known issue which may occur when performing inter-domain transactions due incompatibilities between JMX 1.0 and JMX 1.2. To correct this incompatibility, use the JVM flag -Djmx.serial.form=1.0 as described in JMX 1.2 Implementation in Upgrading WebLogic Application Environments.
Cross Domain Security uses a credential mapper to enable you to configure compatible communication channels between servers in global transactions. For every domain pair that participates in a transaction, a credential mapper is configured. Every domain pair can have a different set of credentials which belong to the
CrossDomainConnector security role. See
Enabling Cross-Domain Security and
Configure a Credential Mapping for Cross-Domain Security in Securing WebLogic Server.
When configuring Cross Domain Security, consider the following:
CrossDomainConnector security role. If the credential mapping is not correct, transactions across the participating domains will fail. See
Configure a Credential Mapping for Cross-Domain Security in Securing WebLogic Server.Excluded Domain Names list of every participating WebLogic Server domain that has Cross Domain Security enabled. If the configuration of the Excluded Domain Names list and the CrossDomainSecurityEnabled flag is not consistent in all participating domains, branches of the transaction will fail.Cross Domain Security Enabled flag is disabled or the domain is in the Excluded Domain Names list, then Security Interoperability Mode is used to establish communication channels for participating domains.Cross Domain Security Enabled flag, there may be a period of time where transactions or other remote calls can fail. For transactions, if the commit request fails, the commit will be retried after the configuration change is complete. If a transaction RMI call fails during any other request, then the transaction times out and the transaction is rolledback. The rollback is retried until AbandonTimeoutSeconds.
Security Interoperability Mode enables you to configure compatible communication channels between servers in global transactions. Use the following steps to configure Security Interoperability Mode:
| Note: | When Security Interoperability Mode is set to performance, you are not required to set domain trust between the domains. |
Establish domain trust by setting a security credential for all domains to the same value in all participating domains.
Every participating server must set the Security Interoperability Mode parameter to the same value:
To configure Security Interoperability Mode for participating servers, see:
The following section provides information on how to configure SecurityInteropMode when transactions use JNDI lookups that require an admin user.
When SecurityInteropMode is set to compatibility Man-in-the-middle attacks are possible.
You must correctly configure compatible communication channels between servers participating in transactions within the same domain using Security Interoperability Mode. See Configuring Security Interoperability Mode.
Use the following information to determine the type of communication channel configuration required for intra-domain transactions.
Each server has a transaction log which stores information about committed transactions coordinated by the server that may not have been completed. WebLogic Server uses the transaction log when recovering from system crashes or network failures. You cannot directly view the transaction log—the records are in a binary format and are stored in the default persistent store for the server.
To take advantage of the migration capability of the Transaction Recovery Service for servers in a cluster, you must store the transaction log in a location that is available to a server and its backup servers, preferably on a dual-ported SCSI disk or on a Storage Area Network (SAN). See Setting the Path for the Default Persistent Store for more information.
If the file system on which the default store saves transaction log records runs out of space or is inaccessible, commit() throws SystemException, and the transaction manager places a message in the system error log. No transactions are committed until more space is available.
Each server instance, including the administration server, has a default persistent store, which is a file-based store that is available to subsystems that do not require explicit selection of a particular store and function best by using the system's default storage mechanism. The transaction manager uses the default persistent store to store transaction log records. In many cases, the default persistent store requires no configuration. However, to enable migration of the Transaction Recovery Service, you must configure the default persistent store so that it stores its data files on a persistent storage solution that is available to other servers in the cluster if the original server fails.
See “ Configure the default persistent store for Transaction Recovery Service migration” in the Administration Console Online Help for instructions.
WebLogic Server uses the default persistent store to store transaction log records. You can select a write policy for the default store to change the way WebLogic Server writes records to disk. You can select one of the following options:
| WARNING: | The Disabled synchronous write policy is not transactionally safe. Do not select this option if your applications use global transactions. |
On Windows, the Direct-Write transaction log file write policy may leave transaction data in the on-disk cache without immediately writing it to disk. This is not transactionally safe because a power failure can cause loss of on-disk cache data. To prevent cache data loss when using the Direct-Write transaction log file write policy on Windows, disable all write caching for the disk (which is enabled by default) or use a battery backup for the system.
See “ Configure the default persistent store for Transaction Recovery Service migration” in the Administration Console Online Help for instructions.
|