|
Maintaining availability of your Oracle WebLogic Integration solution
requires the use of WebLogic Platform tools and the application
of best practices for your enterprise information system (EIS).
For an overview of how Oracle WebLogic Server provides high availability
in cluster environments, see Communications
in a Cluster in Using Oracle WebLogic Server Clusters.
For information about configuring your Oracle WebLogic Integration
solution for high availability, see Understanding
WebLogic Integration High Availability in Deploying
Oracle WebLogic Integration Solutions.
For more information, see the following topics:
High Availability Configurations
To configure a highly available
solution for Trading Partner Integration...
For a pre-deployment checklist
of high availability configuration requirements, see the "Recovery
Checklist" in WebLogic Integration
Application Recovery in the Oracle WebLogic Integration Solutions
Best Practices FAQ.
Important Recommendations
The following provide some important
recommendations regarding Oracle WebLogic Integration solution
availability:
- While developing your application...
- Configure
your retries and retry delays in the async dispatcher queue associated with your application.
so that the transaction retry count (number of retries
* retry delay) of the JPD exceeds the time it takes to
recover a managed server. (Note that configuring retries
and retry delay parameters in the async dispatcher queue associated with your application will
override the retries and retry delay in the JPD.) Configuring
these properties of the async dispatcher queue associated with your application will prevent
problems during recovery associated with certain asynchronous
callbacks (timer, process control) that have no retry
parameters.
- For
information about configuring JMS queue retries and retry
delays, see "Managing Rolled Back, Recovered, Redelivered,
or Expired Messages" in Developing
a WebLogic JMS Application in Programming WebLogic
JMS.
- When an XA-capable enterprise information system
fails...
- Transactions
are often left active until the WebLogic Server TransactionManager
can contact the EIS resource manager to complete the transactions
by either committing the transactions or rolling them
back.
- See also:
Notes on Microsoft SQL Server
If your configuration includes Microsoft SQL Server:
- In cases where a DBMS failure occurs and the DBMS instance
has been used in any XA transaction on a running managed
server, pending XA transactions may be left on that server.
If pending transactions exist on a managed server, graceful
shutdown hangs waiting for those transactions to complete.
Due to recovery issues with Microsoft SQL Server drivers,
sometimes these transactions cannot be successfully completed
(committed or rolled back), making graceful shutdown impossible.
- To
recover normal operations, be sure to follow the recommended
practices described in When an XA-capable
enterprise information system fails...
- When sending multiple asynchronous
requests to a single stateful process, requests may rollback
if you have configured too few retries for the process.
When this occurs, an SQL deadlock message similar to the
following appears in the log:
Exception
in ejbRemote java.sql.SQLException: [BEA][SQLServer JDBC
Driver][SQLServer]Transaction (Process ID 67) was deadlocked
on lock resources with another process and has been chosen
as the deadlock victim. Rerun the transaction.- For
information on setting retries, see "Managing Rolled Back,
Recovered, Redelivered, or Expired Messages" in Developing
a WebLogic JMS Application in Programming WebLogic
JMS.
If your configuration includes Oracle:
- In cases where a DBMS failure occurs and the DBMS instance
has been used in any XA transaction on a running managed
server, pending XA transactions may be left on that server.
If pending transactions exist on a managed server, graceful
shutdown hangs waiting for those transactions to complete.
Due to recovery issues with Oracle thin drivers, sometimes
these transactions cannot be successfully completed (committed
or rolled back), making graceful shutdown impossible.
- To recover normal operations, be sure to follow the recommended practices described in When
an XA-capable enterprise information system fails...
- When a managed server fails and leaves Oracle with an
in-doubt transaction, the following situations may occur:
- You will see an exception
if you try to access the Process Instance Statistics or
Process Instance Summary pages. The ability of the WebLogic
Integration Administration Console to fulfill requests
for process instance information is limited until the
managed server recovers.
- The following Oracle exception
may be thrown:
ORA-01591:
lock held by in-doubt distributed transaction global_tran_id- Other record inserts may hit errors on the table with
the in-doubt transaction. This may prevent the start of
new java processes. Under these circumstances, you should
restart or migrate the failed JTA service. Make sure you
have sufficient retries on running processes to cover
the time that it takes to migrate.
- Other
record inserts may hit errors on the table with the in-doubt
transaction. This may prevent the start of new java processes.
Under these circumstances, you should restart or migrate
the failed JTA service. Make sure you have sufficient
retries on running processes to cover the time that it
takes to migrate.
- For
information about restarting and migrating JTA services,
see Migration in Using WebLogic Server Clusters.
- For
information on setting retries, see "Managing Rolled Back,
Recovered, Redelivered, or Expired Messages" in Developing
a WebLogic JMS Application in Programming WebLogic
JMS.
- It may take Oracle several minutes to return the transaction
to a recovery service. Wait several minutes before starting
recovery. Initiating JTA recovery before Oracle is ready
may cause recovery to fail. Restart recovery, if it fails.
- You
can also administratively resolve the in-doubt transaction
(transaction_id) on
Oracle by executing either a COMMIT
or ROLLBACK command. For example:
COMMIT
FORCE 'local_tran_id'ROLLBACK
WORK FORCE 'local_tran_id'- Another
administrative approach to resolving this situation is
for a qualified Oracle system administrator to analyze
the database, locate the tables where in-doubt transactions
occur, and reduce the number of rows per block in those
tables. This tuning technique should be applied very selectively;
while it reduces the likelihood of overlapping transactions
occurring in those blocks, it also has performance ramifications
for the database.
Related Topics
- Using WebLogic Server Clusters
- Learn about the Oracle WebLogic Server cluster functionality that forms the basis of Oracle WebLogic Integration high availability features.
|
