This document discusses distributed transaction management in Spring and Java EE. It begins with an overview of transactions and their importance for atomic operations across multiple databases or other resources. It then discusses the challenges of distributed transactions that involve multiple machines and components. The document introduces the XA specification for coordinating two-phase commit transactions across heterogeneous systems. It also discusses how Java Transaction API (JTA) and application servers like WebLogic implement the XA specification. Finally, it covers declarative and programmatic transaction demarcation in Spring using annotations and proxies.

1. Distributed Transaction
Management in
Spring & JEE
Mushfekur Rahman
Senior Software Engineer

2. Transaction 101
● Need to perform multiple operations on a datasource for a particular
client action
● Need to make this action atomic
○ All or None
● Well... it cannot be that difficult
○ Obtain a connection
○ Start a transaction
○ Do your DB work
○ Commit the changes
2

3. But… Life’s Not *That* Easy
3

4. Transactions In The Grand Scheme
● Most of the functional real life application usually involves various
components (DBs, Message Brokers, IMDGs, EJBs etc.) *usually* running
in different machines and connected through a network
● We often need to make transactional operations involving multiple
resources
● The simple Local Transaction model doesn’t suffice anymore
● The necessity for something that can talk to and monitor all the resources
and perform transactions across all (e.g. Global Transaction management)
4

5. Hola Distributed Transaction Processing (DTP)
● Distributed Transaction accesses or modifies data stored in multiple
datasources
● A global Transaction Manager (TM) governs whether to commit or rollback
changes made in a distributed transaction
● A good application server should have this functionality out of the box
● But we have various application servers (WebLogic, WildFly, GlassFish)
running numerous applications each one having different transactional
needs and each one talking to their own data sources
● There has to be an open general specification to coordinate between a
TM and other involved components
5

6. X/Open XA Standard
● Specification to facilitate Distributed Transaction Processing (DTP) across
heterogenous components
● Guarantees Atomicity of a transaction among multiple components
using a 2-Phase Commit (2PC) protocol
● Describes the interface between a global transaction manager, data
sources and applications
● The Global Transaction Manager tracks the participants in the transaction
(i.e. XAResources), and works with them to carry out 2PC. XA TM is
separate from an application's interactions with servers. It maintains a log
of its decisions to commit or roll back, which it can use to recover in case
of a system outage.
6

7. X/Open XA Standard (Contd.)
7

8. Java Transaction API (JTA)
● Java Transaction API (JTA) is modelled on top of Open XA spec
● JTA Specifies standard Java interfaces between a transaction manager and
the parties involved in a distributed transaction system such as:
● Resource manager
○ Should implement javax.transaction.xa.XAResource for it to participate in a
distributed transaction
● Application server
○ Should implement javax.transaction.TransactionManager to manage
transactions on behalf of the application
● Transactional applications
○ Should implement javax.transaction.UserTransaction to specify transaction
boundaries of an action 8

9. Putting It Altogether
9

10. WebLogic Transaction Manager
● WebLogic application server provides DTP out of the box
● XA Resources willing to be managed by WL TM need to register
themselves to be managed during the server bootstrapping process
● TM then coordinates the transactions among the resources using 2PC
protocol of XA
● Provides monitoring tools to keep track of the health of transactional
resources
● Provides interface to tweak different transaction configurations
● Individual transactions can be monitored using OEM
10

11. WebLogic Transaction Manager (Contd.)
11

12. Transaction Boundary Demarcation
● Let’s re-iterate a little
○ Three JTA interfaces for DTP
■ XA Resources ✅
■ Transaction Manager ✅
■ Application Programs
● Application programs only need to mark transaction boundaries
● Boundary of a transaction can be set both:
○ Programmatically
○ Declaratively
12

13. Programmatic Transaction Management
● AKA Bean Managed Transaction
● You need to write manual code to demarcate the boundaries of
transaction
● Very little usage in Therap (e.g. backend-test)
● EJB
○ Application code can begin and end transaction through the
javax.transaction.UserTransaction interface
● Spring
○ Recommends using
org.springframework.transaction.support.TransactionTemplate
for programmatic transaction demarcation
13

14. Declarative Transaction Management
● AKA Container Managed Transaction (CMT)
● Convention over Configuration (yay! even less work for programmers)
● EJB
○ CMT in EJB environment is strictly tied to JTA
○ All Session Beans and MDBs may use CMT
○ Delegates the responsibility of starting and committing of a transaction
○ Can set transaction attributes using @TransactionAttribute annotation
○ Rollback occurs for any system exception (RTE) and not app exception
(checked exceptions)
● Spring
○ Need to configure DTM in context configuration
○ Need to set transaction boundaries and attributes using @Transactional
annotation in class and/or method level
14

15. Configure Declarative Transaction in Spring
<tx:jta-transaction-manager/>
Creates a default JtaTransactionManager bean with name "transactionManager",
matching the default bean name expected by <tx:annotation-driven/>.
Automatically detects WebLogic, WebSphere and OC4J: creating a
WebLogicJtaTransactionManager, WebSphereUowTransactionManager or
OC4JJtaTransactionManager, respectively.
<tx:annotation-driven/>
Indicates that transaction configuration is defined by annotations on bean classes, and
that proxies are automatically to be created for the relevant annotated beans.
15

16. Understanding @Transactional
● Marks scope of ongoing transaction and enabled by AOP proxies
● The combination of AOP with transactional metadata yields an AOP
proxy that uses a TransactionInterceptor in conjunction with an
appropriate PlatformTransactionManager implementation to drive
transactions around method invocations
N.B. Proxy is default mode but AspectJ is also an option
16

17. @Transactional Properties
The @Transactional annotation is metadata that specifies that an interface, class, or
method must have transactional semantics; for example, "start a brand new read-only
transaction when this method is invoked, suspending any existing transaction". The
default @Transactional settings are as follows:
● Propagation setting is PROPAGATION_REQUIRED
● Isolation level is ISOLATION_DEFAULT
● Transaction is read/write
● Transaction timeout defaults to the default timeout of the underlying transaction
system, or to none if timeouts are not supported
● Any RuntimeException triggers rollback, and any checked Exception does not
17

18. Did I Say Proxy?
● Classic structural design pattern
● A proxy acts as a substitute for a real service object used by a client and can
weave additional work (cross-cutting concerns) around the target service
○ Transaction Demarcation
○ Access Control
○ Caching etc.
● Spring AOP modes
○ Proxy (Runtime weaving)
○ AspectJ (Compile/Load-time weaving)
● Our choice: Proxy
○ Easier to configure
○ Less load-time overhead
18

19. Understanding Spring AOP Proxies
19

20. Calling Flow via AOP Proxy
20

21. @Transactional Documentation
When using proxies, you should apply the @Transactional annotation only to methods with public visibility. If you do
annotate protected, private or package-visible methods with the @Transactional annotation, no error is raised, but the
annotated method does not exhibit the configured transactional settings. Consider the use of AspectJ (see below) if you
need to annotate non-public methods.
...
Spring recommends that you only annotate concrete classes (and methods of concrete classes) with the @Transactional
annotation, as opposed to annotating interfaces. You certainly can place the @Transactional annotation on an interface
(or an interface method), but this works only as you would expect it to if you are using interface-based proxies. The fact that
Java annotations are not inherited from interfaces means that if you are using class-based proxies ( proxy-target-
class="true") or the weaving-based aspect ( mode="aspectj"), then the transaction settings are not recognized by the
proxying and weaving infrastructure, and the object will not be wrapped in a transactional proxy, which would be decidedly
bad.
21

22. More from Doc
In proxy mode (which is the default), only external
method calls coming in through the proxy are
intercepted. This means that self-invocation, in effect, a
method within the target object calling another method
of the target object, will not lead to an actual transaction
at runtime even if the invoked method is marked with
@Transactional. Also, the proxy must be fully
initialized to provide the expected behaviour so you
should not rely on this feature in your initialization code,
i.e. @PostConstruct.
public class NotSoGreatService {
public void doSomething() {
// code
supposedToDoSomethingInTx();
}
@Transactional
public void supposedToDoSomethingInTx() {
// transactional code
}
} 22

23. @Transactional TL;DR
● In Proxy Mode
○ @Transactional on concrete class and public methods of concrete class
○ Methods are only intercepted through proxy for external calls so no self-
invocation
○ Proxy must be fully initialized before the expected functionality to work so no
usage inside constructor or bean construction callbacks (e.g.
@PostConstruct)
● In AspectJ Mode
○ “Reality can be anything I want.” - Thanos (Avengers: Infinity War)
23

24. How’d I Know If It’s Working?
● Don’t get fooled by the
simplicity of Declarative TM
● If you mess up demarcation, no
error is raised in runtime
● Verify, don’t just rely!
24

25. Step #1: Enable Logs
● Enable debug log for org.springframework.transaction and
additionally for org.springframework.orm.jpa in logback.xml
● First one is not mandatory to trace transactions but helps to relate with
EntityManager sessions
<logger name="org.springframework.orm.jpa" level="debug"/>
<logger name="org.springframework.transaction" level="debug"/>
25

26. Step #2: Tracing Through Logs
26

27. To Learn More
● Official Spring Documentation on Transaction Management
https://docs.spring.io/spring-framework/docs/4.2.x/spring-framework-
reference/html/transaction.html
● Java EE 7 Tutorial: Transactions
https://docs.oracle.com/javaee/7/tutorial/transactions.htm
● Fusion Middleware Programming JTA for Oracle WebLogic Server
https://docs.oracle.com/cd/E24329_01/web.1211/e24377/gstrx.htm#WLJTA11
5
27

28. Thanks!
@Transactional(rollbackFor = SorryItAllWentOverMyHeadException.class)
28