Atomikos Transactions Essentials：Java JTA 实现指南

需积分: 0 25 浏览量更新于2024-07-04 收藏 207KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Java JTA (Java Transaction API) 是一种标准的Java接口，用于处理分布式事务。Atomikos是提供JTA支持的第三方类库，它允许开发者在没有完全实现JTA的应用服务器（如Tomcat）上使用事务管理功能。Atomikos Transactions Essentials是Atomikos提供的一个指南，涵盖了JTA的基础知识以及如何配置和编程Atomikos以实现事务管理。" Java JTA Atomikos 官方文档是为那些想要理解和使用JTA进行分布式事务处理的开发者准备的。文档适用于不仅仅是Spring Boot环境，而是任何Java开发场景。JTA规定了事务管理器应由应用服务器提供，但并非所有服务器都支持，比如Tomcat。在这种情况下，Atomikos等第三方库就显得尤为重要。 JTA概述部分介绍了事务的基本概念，包括嵌套事务。JTA（Java Transaction API）是一种标准，用于协调跨多个数据源的事务。它定义了两阶段提交协议，确保在分布式环境中的一致性和原子性。JTA组件包括用户事务（UserTransaction）、事务管理器（Transaction Manager）和资源管理器（Resource Manager），这些组件共同协作以实现事务的生命周期管理。配置Atomikos Transactions Essentials是文档的重要部分，它指导用户如何设置配置文件，覆盖默认值，以及如何在属性文件中使用Ant风格的引用。文档还包含了一些常见问题及其解答，帮助开发者解决配置过程中可能遇到的问题。编程事务应用程序的章节详细介绍了如何在常规应用程序中使用Atomikos的JDBC和JMS功能，以及如何与UserTransaction交互。这包括获取UserTransaction，使用Atomikos DataSource，处理非XA DataSource，以及利用Atomikos JMS ConnectionFactory。对于需要更高级别的集成，文档提供了使用JTATransactionManager的信息，这是实现XA级事务管理的关键。对于那些想要在不完全支持JTA的应用服务器上实现事务管理的Java开发者，Atomikos Transactions Essentials提供了一条清晰的路径。通过详细的学习和实践，开发者可以掌握如何在自己的应用中有效地引入和管理分布式事务。

资源详情

资源推荐

Chapter 2. JTA Overview

Unless explicitly mentioned, the discussion in this chapter is limited to pure JTA: the content of this

chapter should apply for ANY JTA implementation, not just Atomikos'. Atomikos-specific information is

provided in the later chapters of this manual.

This chapter is a generic JTA overview: it quickly reviews the most important things about JTA that you need to

know in order to use Transactions™. The organization is as follows:

• Transactions

• What is JTA?

• Two-Phase Commit

• JTA Components

• JTA Interactions

• Questions

2.1. Transactions

A transaction is a logical unit of work which effects can either be made permanent in their entirety (committed)

or cancelled in their entirety (rolled back). Before a transaction is committed or rolled back, it is active. Active

transactions' effects are typically invisible to other, concurrent transactions. Consequently, only committed

transactions' effects are visible (can you see why?).

Example 2.1. A typical transaction use case

Imagine that you want to publish a customer-related order message through the Java Message Service (JMS) and at

the same time mark the customer's order data in the database as being processed. The message should not be sent

unless the database can be updated and vice versa.

The concept of transactions requires system-level software support to make these properties hold. A piece of

software that takes care of this is called a transaction manager or transaction service.

2.1.1. Nested Transactions

The nested transaction model is a variant of the normal ('flat') transactional model. Nested transactions differ in

that a subtransaction can be created within an existing transaction (which becomes the parent transaction). The

subtransaction is again a transaction that can be committed or rolled back. The major differences with normal

transactions are in visibility and termination:

• Visibility: an active (sub)transaction's effects are visible to its subtransactions (if any). This means that there is

sharing of updates from parent transaction to subtransaction.

• Termination: a rolled-back subtransaction does not affect its parent transaction. On the other hand, a committed

subtransaction's effects become part of the parent transaction, and become permanent only after the top-level

transaction (the one without a parent) commits.

JTA Overview

2.2. What is JTA?

JTA is short for Sun Microsystems' Java Transaction API and is Sun's (low-level) API for creating transactions in

Java and making your data access operations part of those transactions.

The JTA defines how your application can request transactional functionality on the Java platform. JTA is not

a product in itself, but rather a set of Java interfaces. A vendor-specific JTA implementation referred to as a

transaction manager or transaction service (such as Transactions™) is needed to actually use the functionality

defined in these interfaces. In other words, you can program JTA transactions in your application, but you need the

implementation classes of a JTA-compliant transaction manager vendor in order to run your application.

JTA is a standard part of the Java Enterprise (J2EE) platform and every Enterprise JavaBeans (EJB) application

server should also include a JTA implementation. The JTA is said to be low-level because EJB programmers

typically don't access the JTA API directly or explicitly. Rather, the EJB application server makes the appropriate

calls behind the scenes.

So given that an EJB server will also give you JTA functionality, why should you consider using Atomikos'

TransactionsEssentials? Here are just a few reasons:

• Not all EJB servers will provide a fully functional JTA (even if they claim so). For instance, most -if not all-

open source EJB servers don't even come close to what a transaction manager needs to do, and fail when they

are needed most: after restart or a server crash.

• EJB servers that do provide a reasonable transaction manager are often very expensive, and an overkill for many

solutions that only need a fraction of the J2EE APIs. Atomikos TransactionsEssentials provides transactions at a

fraction of the cost of a full EJB server.

• Atomikos TransactionsEssentials offers more features than defined in the JTA specification.

• Atomikos TransactionsEssentials has better and more functionality than most competitors offer.

• Atomikos TransactionsEssentials was designed for very high performance (there is no extra overhead for JTA

transactions; local transactions and JTA transactions can be expected to be equally fast).

• With Atomikos TransactionsEssentials you can even bring JTA functionality on the J2SE (Java 2 Standard

Edition) platform.

2.3. Two-Phase Commit

In the previous section we have referred to a JTA implementation as a transaction manager or transaction service. A

transaction is a logical unit of work that either happens completely (in all databases or queues that were accessed by

it) or not at all. The transaction manager is the software module that is responsible for ensuring this property. It does

this by executing a two-phase commit termination protocol that addresses all of the resources that a transaction has

used. This two-phase commit happens behind the scenes of your application: you typically don't notice it.

Let us briefly describe two-phase commit with the previous example still in mind. Two-phase commit works in two

phases: a voting phase and a decision phase.

• In the voting (or prepare) phase, the transaction manager will ask both the JMS message queue and the database

whether they can agree with a successful termination or not. Each may return a negative reply, for instance if

there was a time-out which caused the database's work to be rolled back. If one of them replies positively, then

it should make sure it can always make the work permanent (this implies that it can no longer cancel due to an

internal time-out).

• After the transaction manager has received all of the replies (also called 'votes') it will make a global decision on

the outcome of the transaction. This decision will depend on the collected replies:

剩余36页未读，继续阅读

大鹏cool

粉丝: 2w+
资源: 2

Atomikos Transactions Essentials：Java JTA 实现指南

atomikos_3.7_jta项目整合jar包

springboot+mybatis+jta+atomikos解决多数据源事务问题.pdf

spring-boot-starter-jta-atomikos

atomikos mysql

3个以上的数据源，springboot怎么保证事务的一致性

atomikos 集成spring boot 提示DataSourceTransactionManager not found

提供一个atomikos 集成spring boot 的demo

Camunda配置Atomikos事务管理

spring boot 分布式事务

atomikos 事务

JTA和JTS如何使用

How to use atomikos

以上示例哪里使用了atomikos

hibernate+sqlserver整合Atomikos

如何用java实现分布式事务

HIbernate配置JTA的platform

怎样写分布式transaction，用 java

springboot如何使用ShardingSphere提供的Atomikos或Bitronix，事务管理器，给个示例

java分布式事务 demo

java se java ee

最新资源