Exception Handling in Transaction Management

Spring has its own default way of handling exception dealing with transaction management. They are:

• Rollback for all unchecked exceptions
• No rollback for all checked exceptions

The rolling back rules can be changed by using various properties in @Transactional annotation. Some of them have been already discussed in previous section namely “Rolling back rules in a declarative transaction” in which corresponding property setting in Spring configuration file was done. Listing 9-15 shows using properties namely “rollbackForClassname” and “noRollbackForClassname”, in the @Transactional annotation.

Listing 9-15. Using @Transactional other properties in action

[java]@Transactional(isolation = Isolation.DEFAULT,

propagation = Propagation.REQUIRED,

noRollbackForClassName = "com.mybook.loyalty.exceptions.MyNoRollbackException",

rollbackForClassName = "com.mybook.loyalty.exceptions.MyRollbackException")

public void doSomeOperation(String attrib){

//… Do something here….

}[/java]

When to Choose What (Declarative vs. Programmatic)

There is no hard and fast rule saying that which approach is good for application development. Both have their own merits and demerits which needs to considered and accordingly the application team can make a decision on the approach. Some of the noteworthy points which can be considered while making this choice are summarized as below:

• Programmatic transaction management is usually a good idea only if you have a small number of transactional operations.
• If your application has numerous transactional operations, declarative transaction management is usually worthwhile. It keeps transaction management out of business logic, and is not difficult to configure.
• programmatic management is more flexible during development time but less flexible during application life
• declarative management is less flexible during development time but more flexible during application life

Transaction Strategies in Spring

According to the underlying used to manage transactions, transaction strategy in Spring can be divided into two main sections:

• Single connectors strategy (equivalent to Local Transaction Managers) – the underlying technology uses single connector. For example, JDBC uses connection-level transaction and Hibernate as well as JDO uses session-level transaction. We have seen declarative transaction management using aspects (Listing 9-9) and interceptors (Listing 9-14).
• Multiple connector strategy (equivalent to Global Transaction Managers) – the underlying technology has a capability of using mutiple connectors. For example, JTA is the safest bet when such requirement arises. This strategy requires JTA-enabled datasource instances. Listing 9-17 shows this strategy in action using Atomikos, which is an open-source JTA implementation.

Before going to the code listing, I would like to cover JTA implementation available today in the software industry, to make you understand the actual use of having these implementations and how we can use them in our application development.

The JTA implementations

If you would like to have transaction management in standard Java platform and still would like to use JTA, there are stand-alone JTA implementations which can be wired to use the Spring’s JtaTransactionManager. The following section gives information on all such transaction managers at present in the industry which is well known.

JBossTS

JBossTS, formerly known as Arjuna Transaction Service, comes with a very robust implementation, which supports both JTA and JTS API. It doesn’t support out-of-the box integration with Spring, but it is easy to integrate.

Atomikos Transaction Essentials

Atomikos provides out of the box Spring integration. It supports recovery and some exotic features beyond the JTA API. Atomikos supports both database and JMS resources. It also provides support for pooled connections for both database and JMS resources. Listing 9-17 shows integrating Atomikos with Spring.

Bitronix JTA

Bitronix’s JTA implementation is fairly new. Bitronix provides support for both database and JMS resources. Bitronix also provides connection pooling and session pooling out of the box.

Listing 9-17. JTA configuration using Atomikos JTA implementation

[xml]<!–—DataSource configuration — –>

<!–—LoyaltyService target object configuration (proxy concept) — –>

<!–—Atomikos transaction manager —->

<!–— Atomikos User transaction implementation bean —->

<!–—Spring’s JTA transaction manager configuration —->

<!–— The actual service bean which will be used in your application —->

PROPAGATION_REQUIRED

[/xml]

Page Visitors: 9643

The following two tabs change content below.

• Bio
• Latest Posts

Tomcy John

Blogger & Author at javacodebook

He is an Enterprise Java Specialist holding a degree in Engineering (B-Tech) with over 10 years of experience in several industries. He's currently working as Principal Architect at Emirates Group IT since 2005. Prior to this he has worked with Oracle Corporation and Ernst & Young. His main specialization is on various web technologies and acts as chief mentor and Architect to facilitate incorporating Spring as Corporate Standard in the organization.

Latest posts by Tomcy John (see all)

• A Guide to Continuous Improvement for Architects - February 2, 2023
• Cloud-first Architecture Strategy - January 26, 2023
• Architecture Strategy and how to create One - January 24, 2023