The Jakarta Transactions (JTA; formerly Java Transaction API), one of the Jakarta EE APIs, enables distributed transactions to be done across multiple X/Open XA resources in a Java environment. JTA was a specification developed under the Java Community Process as JSR 907. JTA provides for:
In the X/Open XA architecture, a transaction manager or transaction processing monitor (TP monitor) coordinates the transactions across multiple resources such as databases and message queues. Each resource has its own resource manager. The resource manager typically has its own API for manipulating the resource, for example the JDBC API to work with relational databases. In addition, the resource manager allows a TP monitor to coordinate a distributed transaction between its own and other resource managers. Finally, there is the application which communicates with the TP monitor to begin, commit or roll back the transactions. The application also communicates with the individual resources using their own API to modify the resource.
The JTA API consists of classes in two Java packages:
The JTA is modelled on the X/Open XA architecture, but it defines two different APIs for demarcating transaction boundaries. It distinguishes between an application server such as an EJB server and an application component. It provides an interface, javax.transaction.TransactionManager , that is used by the application server itself to begin, commit and roll back the transactions. It provides a different interface, the javax.transaction.UserTransaction , that is used by general client code such as a servlet or an EJB to manage the transactions.
The JTA architecture requires that each resource manager must implement the javax.transaction.xa.XAResource interface in order to be managed by the TP monitor. As stated previously, each resource will have its own specific API, for instance:
The Jakarta Transactions API consists of three elements: a high-level application transaction demarcation interface, a high-level transaction manager interface intended for an application server, and a standard Java mapping of the X/Open XA protocol intended for a transactional resource manager.
The javax.transaction.UserTransaction interface provides the application the ability to control transaction boundaries programmatically. This interface may be used by Java client programs or EJB beans.
The UserTransaction.begin() method starts a global transaction and associates the transaction with the calling thread. The transaction-to-thread association is managed transparently by the Transaction Manager.
Support for nested transactions is not required. The UserTransaction.begin method throws the NotSupportedException when the calling thread is already associated with a transaction and the transaction manager implementation does not support nested transactions.
Transaction context propagation between application programs is provided by the underlying transaction manager implementations on the client and server machines. The transaction context format used for propagation is protocol dependent and must be negotiated between the client and server hosts. For example, if the transaction manager is an implementation of the JTS specification, it will use the transaction context propagation format as specified in the CORBA OTS 1.1 specification. Transaction propagation is transparent to application programs.
The javax.transaction.Transactional annotation provides the application the ability to control transaction boundaries declaratively. This annotation can be applied to any class that the Jakarta EE specification defines as a managed bean (which includes CDI managed beans).
The code sample below illustrates the usage of @Transactional in a request scoped CDI managed bean:
@RequestScopedpublicclassExampleBean{@Transactionalpublicvoidfoo(){// A transaction is active here// Do work}// After the method returns transaction is committed or rolled back}Transactional behavior can be configured via an attribute on the annotation. The available options closely mirror those of the EJB specification.
The javax.transaction.TransactionScoped annotation provides the application the ability to declare that the scope during which a bean lives is tied to the time a given transaction is active.
The code sample below illustrates the usage of @TransactionScoped in a request scoped CDI managed bean:
@TransactionScopedpublicclassTxScopedBean{publicintnumber;publicintgetNumber(){returnnumber;}publicvoidsetNumber(intnumber){this.number=number;}}@RequestScopedpublicclassExampleBean{@InjectprivateTxScopedBeantxScopedBean;@Transactionalpublicvoidfoo(){txScopedBean.setNumber(1);}@Transactionalpublicvoidbar(){System.out.print(tXscopedBean.getNumber());}}If method foo() is first called on a managed instance of ExampleBean and then subsequently method bar() is called, the number printed will be 0 and not 1. This is because each method had its own transaction and therefore its own instance of TxScopedBean. The number 1 that was set during the call to foo() will therefore not be seen during the call to bar().
EJB servers are required to support the UserTransaction interface for use by EJB beans with the BEAN value in the javax.ejb.TransactionManagement annotation (this is called bean-managed transactions or BMT). The UserTransaction interface is exposed to EJB components through either the EJBContext interface using the getUserTransaction method, or directly via injection using the general @Resource annotation. Thus, an EJB application does not interface with the Transaction Manager directly for transaction demarcation; instead, the EJB bean relies on the EJB server to provide support for all of its transaction work as defined in the Jakarta Enterprise Beans Specification. (The underlying interaction between the EJB Server and the TM is transparent to the application; the burden of implementing transaction management is on the EJB container and server provider. [1] )
The code sample below illustrates the usage of UserTransaction via bean-managed transactions in an EJB session bean:
@Stateless@TransactionManagement(BEAN)publicclassExampleBean{@ResourceprivateUserTransactionutx;publicvoidfoo(){// start a transactionutx.begin();// Do work// Commit itutx.commit();}}Alternatively, the UserTransaction can be obtained from the SessionContext:
@Stateless@TransactionManagement(BEAN)publicclassExampleBean{@ResourceprivateSessionContextctx;publicvoidfoo(){UserTransactionutx=ctx.getUserTransaction();// start a transactionutx.begin();// Do work// Commit itutx.commit();}}Note though that in the example above if the @TransactionManagement(BEAN) annotation is omitted, a JTA transaction is automatically started whenever foo() is called and is automatically committed or rolled back when foo() is exited. Making use of a UserTransaction is thus not necessary in EJB programming, but might be needed for very specialized code.
The UserTransaction should be available under java:comp/UserTransaction (if a JTA implementation is installed in the environment).
Jakarta Enterprise Beans is one of several Java APIs for modular construction of enterprise software. EJB is a server-side software component that encapsulates business logic of an application. An EJB web container provides a runtime environment for web related software components, including computer security, Java servlet lifecycle management, transaction processing, and other web services. The EJB specification is a subset of the Java EE specification.
Jakarta EE, formerly Java Platform, Enterprise Edition and Java 2 Platform, Enterprise Edition (J2EE), is a set of specifications, extending Java SE with specifications for enterprise features such as distributed computing and web services. Jakarta EE applications are run on reference runtimes, that can be microservices or application servers, which handle transactions, security, scalability, concurrency and management of the components they are deploying.
Java Platform, Standard Edition is a computing platform for development and deployment of portable code for desktop and server environments. Java SE was formerly known as Java 2 Platform, Standard Edition (J2SE).
A Jakarta Servlet, formerly Java Servlet is a Java software component that extends the capabilities of a server. Although servlets can respond to many types of requests, they most commonly implement web containers for hosting web applications on web servers and thus qualify as a server-side servlet web API. Such web servlets are the Java counterpart to other dynamic web content technologies such as PHP and ASP.NET.
Java Data Objects (JDO) is a specification of Java object persistence. One of its features is a transparency of the persistence services to the domain model. JDO persistent objects are ordinary Java programming language classes (POJOs); there is no requirement for them to implement certain interfaces or extend from special classes. JDO 1.0 was developed under the Java Community Process as JSR 12. JDO 2.0 was developed under JSR 243 and was released on May 10, 2006. JDO 2.1 was completed in Feb 2008, developed by the Apache JDO project. JDO 2.2 was released in October 2008. JDO 3.0 was released in April 2010.
An application server is a server that hosts applications or software that delivers a business application through a communication protocol.
Swing is a GUI widget toolkit for Java. It is part of Oracle's Java Foundation Classes (JFC) – an API for providing a graphical user interface (GUI) for Java programs.
Jakarta Faces, formerly Jakarta Server Faces and JavaServer Faces (JSF) is a Java specification for building component-based user interfaces for web applications and was formalized as a standard through the Java Community Process being part of the Java Platform, Enterprise Edition. It is also an MVC web framework that simplifies the construction of user interfaces (UI) for server-based applications by using reusable UI components in a page.
Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices and service-oriented networks. Those resources are represented by objects called MBeans. In the API, classes can be dynamically loaded and instantiated. Managing and monitoring applications can be designed and developed using the Java Dynamic Management Kit.
A distributed transaction is a database transaction in which two or more network hosts are involved. Usually, hosts provide transactional resources, while the transaction manager is responsible for creating and managing a global transaction that encompasses all operations against such resources. Distributed transactions, as any other transactions, must have all four ACID properties, where atomicity guarantees all-or-nothing outcomes for the unit of work.
Jakarta Connectors are a set of Java programming language tools designed for connecting application servers and enterprise information systems (EIS) as part of enterprise application integration (EAI). While JDBC is specifically used to establish connections between Java applications and databases, JCA provides a more versatile architecture for connecting to legacy systems. JCA was developed through the Java Community Process, with versions including JSR 16, JSR 112, and JSR 322.
Apache Beehive is a discontinued Java Application Framework that was designed to simplify the development of Java EE-based applications. It makes use of various open-source projects at Apache such as XMLBeans. Apache Beehive uses Java 5, including JSR-175, a facility for annotating fields, methods, and classes so that they can be treated in special ways by runtime tools. It builds on the framework developed for BEA Systems Web logic Workshop for its 8.1 series. BEA later decided to donate the code to Apache.
In software engineering, a plain old Java object (POJO) is an ordinary Java object, not bound by any special restriction. The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000:
"We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely."
For transaction processing in computing, the X/Open XA standard is a specification released in 1991 by X/Open for distributed transaction processing (DTP).
The Spring Framework is an application framework and inversion of control container for the Java platform. The framework's core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE platform. The framework does not impose any specific programming model.. The framework has become popular in the Java community as an addition to the Enterprise JavaBeans (EJB) model. The Spring Framework is open source.
Jakarta PersistenceAPI is a Jakarta EE application programming interface specification that describes the management of relational data in enterprise Java applications.
Java Database Connectivity (JDBC) is an application programming interface (API) for the Java programming language which defines how a client may access a database. It is a Java-based data access technology used for Java database connectivity. It is part of the Java Standard Edition platform, from Oracle Corporation. It provides methods to query and update data in a database, and is oriented toward relational databases. A JDBC-to-ODBC bridge enables connections to any ODBC-accessible data source in the Java virtual machine (JVM) host environment.
IBM WebSphere Optimized Local Adapters (OLA or WOLA) is a functional component of IBM's WebSphere Application Server for z/OS that provides an efficient cross-memory mechanism for calls both inbound to WAS z/OS and outbound from z/OS. Because it avoids the overhead of other communication mechanisms, it is capable of high volume exchange of messages. WOLA is an extension to the existing cross-memory exchange mechanism of WAS z/OS, with WOLA providing an external interface so z/OS address spaces outside the WAS z/OS server may participate in cross-memory exchanges. WOLA supports connectivity between a WAS z/OS server and one or more of the following: CICS, IMS, Batch, UNIX Systems Services and ALCS. WOLA was first made available in WAS z/OS Version 7, Fixpack 4 (7.0.0.4). Functional enhancements have appeared in subsequent fixpacks as documented in this article.
WildFly, formerly known as JBoss AS, or simply JBoss, is an application server written by JBoss, now developed by Red Hat. WildFly is written in Java and implements the Java Platform, Enterprise Edition specification. It runs on multiple platforms.
Composite entity is a Java EE Software design pattern and it is used to model, represent, and manage a set of interrelated persistent objects rather than representing them as individual fine-grained entity beans, and also a composite entity bean represents a graph of objects.
