Support type-safe transaction rollback rules

[hduyyg]

Source code in question：

private int getDepth(Class<?> exceptionClass, int depth) {
	if (exceptionClass.getName().contains(this.exceptionName)) {
		// Found it!
		return depth;
	}
	// If we've gone as far as we can go and haven't found it...
	if (exceptionClass == Throwable.class) {
		return -1;
	}
	return getDepth(exceptionClass.getSuperclass(), depth + 1);
}

test code:

public class CustomException extends Exception {
}

public class CustomExceptionX extends Exception {
}

@Override
@Transactional(rollbackFor = CustomException.class)
public void testTransaction() throws Exception {
    taskMapper.softDeleteById(1, "test");
    if (1 == 1) {
        throw new CustomExceptionX();
    }
}

[sbrannen]

This is by design and was originally implemented using contains() for use in XML configuration files where users often specified the simple name of a custom exception type instead of the fully qualified class name.

You can see examples of this in the reference docs.

<tx:advice id="txAdvice" transaction-manager="txManager">
  <tx:attributes>
    <tx:method name="get*" read-only="true" rollback-for="NoProductInStockException"/>
    <tx:method name="*"/>
  </tx:attributes>
</tx:advice>

With your proposal to use equals() instead of contains(), configuration like that would no longer work since NoProductInStockException would only ever be equal to the fully qualified class name if the NoProductInStockException was declared as a top-level class in the default package -- which is rather unlikely.

Please take note of the Javadoc for RollbackRuleAttribute as well:

NB: Consider carefully how specific the pattern is, and whether to include package information (which is not mandatory). For example, "Exception" will match nearly anything, and will probably hide other rules. "java.lang.Exception" would be correct if "Exception" was meant to define a rule for all checked exceptions. With more unusual exception names such as "BaseBusinessException" there's no need to use a fully package-qualified name.

Similar documentation exists for the rollbackForClassName attribute in @Transactional.

---

The Javadoc for the RollbackRuleAttribute(Class) constructor states the following,

Create a new instance of the RollbackRuleAttribute class.

This is the preferred way to construct a rollback rule that matches the supplied Exception class, its subclasses, and its nested classes.

However, that last sentence is not honored in the current implementation, since the type information (supplied via the Class reference) is not taken into account in the implementation of getDepth(...).

[sbrannen]

Correction to my previous statement. The Javadoc for the RollbackRuleAttribute(Class) constructor is mostly correct.

However, the documentation for rollback rules can be improved to warn that unintentional matches may arise if the name of a thrown exception contains the name of a registered exception type.

I am therefore repurposing this issue to improve the documentation.