WebLogic DataSource Configuration Considerations

This article transferred from: http://blog.csdn.net/yangjun2/article/details/7044736

Directory

1. Transaction options
1. Enable support for global transactions by using non-XA JDBC drivers
2. Understanding record Previous Resource options
1. Programming considerations and limitations for LLR data sources
2. LLR Management considerations and limitations for data sources
3. Understanding simulation Two-phase commit transaction options
1. Simulate the limitations and risks of two-phase commits using non-XA drivers
1. Exploratory completion and inconsistent data
2. Cannot resume pending transactions
3. Performance loss that can occur when using non-XA resources in a multi-server configuration
4. Only one non-XA participant

WebLogic Configuration Considerations When creating DataSource, record the doc for WebLogic.

Transaction options

When you use the management console to configure a JDBC data source, WebLogic Server automatically selects specific transaction options based on the type of JDBC driver:

• For the XA driver, the system automatically chooses the two-phase commit protocol for global transaction processing.
• for non-XA drivers, local transactions are supported by definition, and WebLogic Server provides the following options

  Support for global transactions: (selected by default) if you want to use a connection from a data source in a global transaction, select this option even if the XA driver is not selected. For more information, see Enable support for global transactions by using non-XA JDBC drivers.

  When support global transactions is selected, you must also select the protocol to use for the transaction branch when processing global transactions for WebLogic Server:

  • Log previous resource: Using this option, the transaction branch using the connection is processed as the last resource in the transaction and processed as a local transaction. The commit record for a two-phase commit (two-phase commit, short 2PC) is inserted into the table of the resource itself, and this result determines the success or failure of the global transaction preparation phase. This option has some performance benefits and higher data security than emulation two-phase commit, but it has some limitations. See Understanding the "record previous resource" option.

    Attention:

    The data source used by a multi-data source does not support logging the previous resource.

  • Simulation Two-phase commit: Using this option, the transaction branch that uses the connection always returns success information for the transaction preparation phase. This option provides performance benefits, but there is also a risk of data corruption in some failure scenarios. You can select this option only if the application allows for exploratory scenarios.
  • One-stage commit: (selected by default) with this option, the connection from the data source can only be a unique contributor to the global transaction, and the transaction is done using a one-phase commit optimization. If more than one resource participates in the transaction, the transaction manager throws an exception when it is called on a 1PC resource XAResource.prepare .

Enable support for global transactions by using non-XA JDBC drivers

If you use global transactions in your application, you should use the XA JDBC driver to create a database connection in the JDBC data source. If an XA driver is not available for your database, or if you do not want to use the XA driver, you should enable support for global transactions in the data source. Support for global transactions should also be enabled if the application meets any one of the following conditions:

• Using the EJB container in WebLogic Server to manage transactions
• Include multiple database updates in a transaction
• Access multiple resources in one transaction (such as database and Java message Service (JMS))
• Use the same data source on multiple servers (clustered or non-clustered)

Understanding the "Record previous resource" option

WebLogic Server supports "Logging previous resource" (Logging last Resource, or LLR) transaction optimization through a JDBC data source. LLR is a performance enhancement option that allows a non-XA resource to participate in global transactions with the same ACID guarantee as XA. LLR is an improved result of "last Agent optimization". It differs from the previous agent optimization because it is safe for transactions. The LLR resource uses a local transaction for its transactional work. The WebLogic Server transaction manager prepares all other resources in the transaction and then determines the commit decision for the global transaction based on the results of the local transaction for the LLR resource.

LLR optimizations improve performance in the following ways:

• Eliminates the need to connect to the database using the XA JDBC driver. Xa jdbc drivers are often inefficient compared to non-XA JDBC drivers.
• Reduces the processing steps required to complete a transaction, which also reduces network traffic and disk I/O times.
• Eliminates the need for XA processing at the database level

When a connection in a data source configured for LLR participates in a two-phase commit (2PC) global transaction, the WebLogic Server transaction manager completes the transaction in the following ways:

• The preparation is called on all other (XA compliant) transaction participants.
• Inserts a commit record into the LLR contributor's table (not the file-based transaction log).
• Commits the local transaction of the LLR contributor (including transaction commit record insertion and SQL work for the application).
• The commit is invoked on all other transactional participants.

Programming considerations and limitations for LLR data sources

You can use a JDBC connection from a LLR-enabled data source in your application in a way that uses a JDBC connection from any other data source: After you start a transaction , locate the data source in the JNDI tree, and then request a connection from that data source. However, when using LLR optimization, WebLogic Server manages the connection requests internally and handles transactions in a different way than is used in XA transactions.

Please note the following items:

• When programming with a LLR data source, you must start the global transaction before calling the getconnection of the LLR data source. Calling getconnection before starting the global transaction causes all operations on the connection to be outside the global transaction.
• Only one internal JDBC LLR connection is reserved for each transaction, and the connection is used for the entire transaction.
• A reserved connection is always hosted on the coordinator server for that transaction. Make sure that the data source is located on the coordination server or cluster.
• For other JDBC connection requests from a data source of the same name in this transaction, the operation is routed to the reserved connection from the original connection request, even if the subsequent request is made on a different instance of the data source (that is, the data source on the server that is on the same server as the original data source that provided the connection to the first request). The same is true. Please note the following:
  • In terms of functionality and performance, routing LLR connections may not be as local-hosted XA connections.
  • Connection request routing limits the number of concurrent transactions. The maximum number of concurrent LLR transactions equals the configured size (maxcapacity) of the JDBC LLR data source for the coordinator.
  • The ability to route connections is less than the functionality of local connections, which can cause failures. Specifically, the non-serialized "custom" data type in query ResultSet may fail.
• Only instances of a single LLR data source can participate in a particular transaction. A single LLR data source can have instances on multiple WebLogic servers, and if two data sources have the same configured name, the two data sources are considered to be the same. If multiple LLR data source instances are detected, and they are not instances of the same data source, the transaction manager rolls back the transaction.
• weblogic.transaction.nonxa.NonXAResourceA resource adapter (connector) that implements an interface cannot participate in global transactions where the LLR resource also participates, because both must be the last resource in the transaction. If both resource types participate in the same transaction, the method of the transaction is raised when this conflict is detected commit() javax.transaction.RollbackException .
• Because LLR connections use separate local transactions for database processing, any changes (and any locks made) that use XA connections to the same database during LLR processing are not visible, even if all processing occurs in the same global transaction. In some cases, this may cause a deadlock in the database. XA and LLR processing should not be mixed in the same database in a single global transaction.
• A connection from a LLR data source cannot participate in a transaction that is coordinated by an external transaction manager, such as a request agent by a remote object or a transaction initiated by Tuxedo.
• A global transaction cannot be spanned to another legacy domain that contains a data source with the same name as a LLR data source.
• For JDBC LLR 2PC transactions, if the transaction data is too large to mount into the LLR table, the transaction will fail and a rollback exception is generated during the commit. This can happen if your application adds many transaction properties during the transaction process. If this happens, the database administrator can manually create a table with a larger column.

LLR Management considerations and limitations for data sources

When configuring a JDBC data source with LLR enabled, consider the following requirements and limitations:

• For each server, there is a LLR table:
  • Multiple LLR data sources can share a table.
  • If the table is not found, WebLogic Server automatically creates the table.
  • The default name is WL_LLR_ SERVERNAME . In the administration console, select the server > Configuration > General tab, and then configure the table name under Advanced options on this tab.
• If the database is turned off during boot or the LLR table is inaccessible, the server will not boot.
• Multiple servers must not share the same LLR table. The bootstrap checks to ensure that the domain and server names match the domain and server names that are stored in the table when the table is created. If WebLogic server detects that multiple servers are sharing the same LLR table, WebLogic server shuts down one or more servers.
• LLR supports migration of server migrations and transaction recovery services. To migrate using transaction recovery services, make sure that each LLR resource is anchored to the cluster or to the group of candidates in the clusters. See " Recovering transactions for a failed clustered server."
• The LLR transaction option is not allowed in the JDBC application module.
• Using the LLR transaction option is not supported in data sources used by multiple data sources.
• If a credential mapping is used on a LLR data source, all mapped users must have write access to the LLR table.
• You cannot use the JDBC XA driver to create a database connection in the JDBC LLR data source. If the JDBC driver used in the JDBC LLR data source supports XA, a warning message is logged and the data source participates in the transaction as a full XA resource rather than as a LLR resource.
• The transaction statistics for the LLR resource are tracked under Nonxaresource.

Understanding the "simulate two-phase commit" Transaction option

If you need to use a JDBC data source to support distributed transactions, but there are no XA-compliant drivers for your DBMS to use, you can select simulate two-phase commit for a data source's non-XA driver option to simulate a two-phase commit of a transaction that participates in a connection from that data source. This option is an advanced option on the General tab, which you can access by selecting the JDBC data sourceconfigurationGeneral tab.

When you select simulate two-phase commit (set to) for the non-XA driver option EnableTwoPhaseCommit true , non-XA JDBC resources are always XAResource.prepare returned during the () method call XA_OK . The resource attempts to commit or roll back its local transaction in response to subsequent XAResource.commit () or XAResource.rollback () calls. If a resource commits or rolls back fails, it causes a tentative error. Application data may be in an inconsistent state due to exploratory failure.

EnableTwoPhaseCommit false non-XA JDBC resources cause () failure when the simulate two-phase commit (set to) is not selected in the console for the non-XA driver option XAResource.prepare . When only one resource participates in a transaction, the one-stage optimization skips XAResource.prepare (), and in most cases, the transaction commits successfully.

Attention:

When you select simulate two-phase commit for the non-XA driver option, there is a risk that data integrity will be compromised. BEA recommends using the XA compliant JDBC driver or the "record previous resource" option (instead of using the "simulate two-phase commit" option). Be sure to consider these risks before enabling this option.

This non-XA JDBC driver support is commonly referred to as the "JTS driver" because WebLogic Server uses WebLogic JTS drivers internally to support this feature.

Simulate the limitations and risks of two-phase commits using non-XA drivers

WebLogic Server supports non-XA JDBC resources to participate in global transactions using the simulate two-phase commit data source transaction option, but there are some limitations that you must consider when designing your application (to use such a data source). Because non-XA drivers do not conform to the xa/2pc contract and only support one-phase commit and rollback operations, WebLogic Server (through the JTS driver) must compromise to allow resources to participate in a transaction that is controlled by the transaction manager.

Before you use simulate two-phase commit for the non-XA driver option, consider the following limitations and risks:

Exploratory completion and inconsistent data

When you select simulate two-phase commit () for a non-XA resource enableTwoPhaseCommit = true , the transaction preparation phase of a non-XA resource is always successful. Therefore, non-XA resources do not really participate in the two-phase commit (2PC) protocol and are prone to failure. If a failure occurs in a non-XA resource after the preparation phase, the non-XA resource may roll back the transaction when the XA transaction contributor commits the transaction, leading to exploratory completion and inconsistent data.

Because of the risk of data integrity breaches, the simulate two-phase commit option should only be used in applications that allow exploratory scenarios.

Cannot resume pending transactions

Because non-XA drivers operate on local database transactions only, there is no concept of a transaction pending state in the database about the external transaction manager. When invoked on a non-XA resource XAResource.recover() , the method always returns an empty set of Xid (transaction ID), even if there may be a transaction that needs to be committed or rolled back. As a result, applications that use non-XA resources in global transactions cannot recover from system failures and maintain data integrity.

Performance loss that can occur when using non-XA resources in a multi-server configuration

Because WebLogic Server relies on database local transactions associated with a particular JDBC connection to support non-XA resources in global transactions, when an application accesses the same JDBC data source in multiple WebLogic Server instances through a global transaction context, JT The S driver always routes the JDBC operation to the first connection established by the application in a transaction. For example, if an application initiates a transaction on one server, accesses a non-XA JDBC resource, and then makes a remote method call to another server (invocation, or RMI) and accesses a data source that uses the same underlying JDBC driver, the The JTS driver recognizes that the resource has a connection associated with a transaction on another server and sets an RMI redirect to the actual connection on the first server. All operations on the connection are performed on a connection that is established on the first server. This behavior can cause a performance penalty because of the overhead associated with setting these remote connections and RMI calls to a physical connection.

Only one non-XA participant

When a non-XA resource (whose emulation two-phase commit is selected) is registered with the WebLogic Server transaction manager, the resource is registered with the name of the class that implements the XAResource interface. Because all non-XA resources whose "emulation two-phase commit" is selected are using the JTS driver for the XAResource interface, all non-XA resources that participate in a global transaction are registered with the same name (their "emulation two-phase commit" is selected). If more than one non-XA resource is used in a global transaction, it can cause a naming conflict or a tentative failure may occur.

WebLogic DataSource Configuration Considerations