이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 6. Transactions


Data Virtualization utilizes XA transactions for participating in global transactions and for demarcating its local and command scoped transactions.

For information about advanced transaction technologies that are provided for Data Virtualization through the Narayana community project, see the Narayana documentation.

Table 6.1. Data Virtualization transaction scopes
ScopeDescription

Command

Treats the user command as if all source commands are executed within the scope of the same transaction. The AutoCommitTxn execution property controls the behavior of command level transactions.

Local

The transaction boundary is local defined by a single client session.

Global

Data Virtualization participates in a global transaction as an XA resource.

The default transaction isolation level for Data Virtualization is READ_COMMITTED.

6.1. AutoCommitTxn Execution Property

User level commands can execute multiple source commands. To control the transactional behavior of a user command when not in a local or global transaction, you can specify the AutoCommitTxn execution property.

Table 6.2. AutoCommitTxn Settings
SettingDescription

OFF

Do not wrap each command in a transaction. Individual source commands may commit or rollback regardless of the success or failure of the overall command.

ON

Wrap each command in a transaction. This mode is the safest, but may introduce performance overhead.

DETECT

This is the default setting. Will automatically wrap commands in a transaction, but only if the command seems to be transactionally unsafe.

The concept of command safety with respect to a transaction is determined by Data Virtualization based upon command type, the transaction isolation level, and available metadata. A wrapping transaction is not needed if the following criteria are true:

  • The user command is fully pushed to the source.
  • The user command is a SELECT (including XML) and the transaction isolation is not REPEATABLE_READ nor SERIALIABLE.
  • The user command is a stored procedure, the transaction isolation is not REPEATABLE_READ nor SERIALIABLE, and the updating model count is zero. For more information, see Updating model count.

The update count may be set on all procedures as part of the procedure metadata in the model.

6.2. Updating Model Count

The term "updating model count" refers to the number of times any model is updated during the execution of a command. It is used to determine whether a transaction, of any scope, is required to safely execute the command.

Table 6.3. Updating model count settings
CountDescription

0

No updates are performed by this command.

1

Indicates that only one model is updated by this command (and its subcommands). The success or failure of that update corresponds to the success or failure of the command. It should not be possible for the update to succeed while the command fails. Execution is not considered transactionally unsafe.

*

Any number greater than 1 indicates that execution is transactionally unsafe and an XA transaction will be required.

6.3. JDBC and transactions

JDBC API functionality

The transaction scopes in Transactions map to the following JDBC modes:

Command
Connection autoCommit property set to true.
Local
Connection autoCommit property set to false. The transaction is committed by setting autoCommit to true or calling java.sql.Connection.commit. The transaction can be rolled back by a call to java.sql.Connection.rollback
Global
The XAResource interface provided by an XAConnection is used to control the transaction. Note that XAConnections are available only if Data Virtualization is consumed through its XADataSource, org.teiid.jdbc.TeiidDataSource. JEE containers or data access APIs typically control XA transactions on behalf of application code.

J2EE usage models

J2EE provides the following ways to manage transactions for beans:

Client-controlled
The client of a bean begins and ends a transaction explicitly.
Bean-managed
The bean itself begins and ends a transaction explicitly.
Container-managed
The application server container begins and ends a transaction automatically.

In any of the preceding cases, transactions can be either local or XA transactions, depending on how the code and descriptors are written. The XA specification does not require some types of beans (for example, stateful session beans and entity beans) to work with non-transactional sources. However, according to the specification, optionally, application servers can allow the use of these beans with non-transactional sources, with the caution that such usage is not portable or predictable. Generally speaking, to provide for most types of EJB activities in a portable fashion, applications require a mechanism for managing transactions.

6.4. Limitations

  • The client setting of transaction isolation level is propagated only to JDBC connectors; the setting is not propagated to other connector types. The default transaction isolation level can be set on each XA connector. However, the isolation level is fixed, and cannot be changed at runtime for specific connections or commands.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.