In the following scenario, the client begins a transaction. After this, the client invokes some components; for example, EJB, CDI beans, or web components running on more application servers. The transaction of the client container is propagated to various components that the client calls. This scenario is like the multiple application server example seen in the previous section, with a difference that an external client starts the transaction context, instead of starting this inside the component container of the application servers.
Here is a figure explaining a distributed transaction--client demarcation:

These distributed transaction scenarios illustrate the necessity of distributed transaction support in Java EE. The Java EE application server becomes the coordinator of distributed transactions. It coordinates the transaction across different resources, servers, and components. But how does a distributed transaction work under the covers? What is the protocol that a transaction coordinator uses to coordinate disparate resources? The protocol that a transaction coordinator uses is known as a two-phase commit, which we will discuss next.

These transactions cannot work without a coordinator that keeps trace of the transactions and the state of the resources. Only an application server can do it. In the following section, we will see how the application server coordinates these distributed transactions using the two-phase commit protocol mentioned in the previous Distributed transactions and the JTA section.