WebLogic Server MT supports transaction processing in a multiple partition environment. The scope of the transactions can be either at the domain or partition level.
This chapter includes the following sections:
A Logging Last Resource (LLR) data source, JDBC TLog data source, or a Determiner Resource cannot be registered in a partition. In this release of WebLogic Server, any attempt to register these resources at the partition level will result in a system exception.
This restriction is because a WebLogic Server instance cannot start if any of these resources is not available. Therefore, in a multitenant environment, an inaccessible shared by other partitions. If a server is allowed to start despite the inaccessibility of a resource (and hence its commit records), the recovery of resources enlisted in transactions that also enlisted those resources may be non-atomic as the lack of a commit record would result in a rollback of those resources.
If you still want to use LLR for the resource commit ordering it inherently provides, then use the first resource commit functionality provided in the WebLogic Server 12.2.1 release. Because this feature requires a true XA resource rather than the local-transaction-based LLR resource, it does not provide the performance benefits that LLR offers and it does not require an LLR table. LLR data sources are pinned to the server that they are deployed on, but XA data sources are not. Therefore, in the case where multiple servers are enlisted in a transaction, the two-phase commit flow may be slightly different. See First Resource Commit Ordering in Developing JTA Applications for Oracle WebLogic Server.
Stateful EJB client failover after a live migration of its resource groups to another cluster takes longer than a failover within a cluster because the cluster service waits for the result of the replica search from the cluster members with ClusterMBean.getSessionStateQueryRequestTimeout(), which has a default value of 30 seconds. Therefore, during the failover of a stateful EJB invocation after a live migration of its resource group to another cluster, if there is a transaction on the thread, the transaction may time out during the failover of the stateful EJB method invocation if the transaction timeout value is not sufficiently long enough. The default transaction timeout is 30 seconds.
To avoid transaction timeout during a resource group live migration across clusters that involve a stateful EJB client, increase the transaction timeout value before the resource group migration. You can then reset the timeout to its previous value when all the clients that use the stateful EJB that are migrated have failed over to the target cluster. For example, if there is an EJB that invokes the stateful EJB in a container managed transaction, increase the trans-timeout-seconds deployment descriptor for the EJB application using the WebLogic Server Administration Console. For more information see, EJB: Configuration.