support for setRollbackOnly() in chunk transaction [BATCH-824]

[spring-projects-issues]

Gaetan Pitteloud opened BATCH-824 and commented

One of our batch developer wants to programmatically rollback the transaction in a batch, by invoking TransactionStatus.setRollbackOnly() on the status returned by the transaction manager.

The problem is that the tx status is only local to the doExecute() method of the ItemOrientedStep, and there is no way to access it. Would it be possible to share it, e.g. in a ThreadLocal, in the same way transaction support for aop is achieved ? ItemReader and ItemWriter would then be able to programmatically rollback without throwing an exception.

---

Affects: 1.1.2, 2.0.0.M1

[spring-projects-issues]

Lucas Ward commented

I'm not sure I understand why this would be needed? If you throw an exception from a writer, the transaction will be rolledback according to the transaction attributes in the step.

[spring-projects-issues]

Gaetan Pitteloud commented

Using spring-batch, we were able to reuse some of our components (including low-level services and daos) that were developed for the online world, into the batch application, as collaborators of ItemReaders and ItemWriters. In the online world, these services are configured to run in a transaction that is started by a facade, which transaction is in turn managed using the Spring TransactionInterceptor.

As this interceptor stores the status in a thread local, we have provided an interface (some kind of transaction service) for the developers who need it, so that they can set the rollbackOnly status on the transaction in the implementation of their services, without explicitely throwing an exception. This is useful when an exception is encountered, but the develper wants to continue processing the input (maybe in order to provide the list of all problems to the user); setting the rollbackOnly flag on the transaction status ensures the transaction will not commit.

By the way, the ThreadLocal might not be the right solution to share the TransactionStatus in the batch environment: storing it as a RepeatContext attribute would be the way to go. Actually, any solution that allows me to access it would be sufficent.

I have thought of a workaround for this issue: wrap the transaction manager in a proxy that shares (as a RepeatContext attribute) the status before returning it in getTransaction(), and removes it from the context on commit()/rollback(). The real transaction manager is injected into this proxy, which in turn is injected into the ItemOrientedStep, instead of the real transaction manager.

[spring-projects-issues]

Lucas Ward commented

Ah, now I understand what you're trying to do a little bit better. This is something we were already planning to address: BATCH-805

[spring-projects-issues]

Dave Syer commented

I don't think BATCH-805 is the same requirement. How would you expect to get access to the RepeatContext?

I don't think I would recommend relying on the ThreadLocal with core Spring either. I really don't see why it is so difficult to manage the logic yourself and throw an exception to force a rollback, e.g. just set a local boolean flag and check it before you return from the business logic.

[spring-projects-issues]

Gaetan Pitteloud commented

The reason for this request is to reuse in a batch a service that was built for another application.

The complete history is as follows: a long time ago, the service was written as an EJB, and the business required to use setRollbackOnly() instead of throwing an exception; this was supported with a call to ejbContext.setRollbackOnly(). Then, we dropped EJB, and the service is now implemented as a POJO, and the transaction is driven by a spring TransactionInterceptor. The service did not have to change a lot: just replace ejbContext.setRollbackOnly() with TransactionInterceptor.currentTransactionStatus().setRollbackOnly(), without changing the business logic at all.

Now, this same service is used in a batch application. Since the transaction is still driven by spring, it sounds legitimate to be able to get a handle on the transactionStatus in order to invoke setRollbackOnly(). The service is now configured with a strategy that provides a way to set the rollbackOnly flag, or give access to the transaction status. Such a strategy is provided when the transaction is started with the TransactionInterceptor, but is missing for the spring-batch transaction.

I was thinking of sharing the transactionStatus as a RepeatContext attribute, so that the setRollbackOnly() method of the strategy would be as follows:

public void setRollbackOnly() {
RepeatContext ctx = RepeatSynchronizationManager.getContext();
TransactionStatus status = ctx.getAttribute("TRANSACTION_STATUS");
status.setRollbackOnly();
}

while the ItemOrientedStep would contain the following additional lines (line numbers based on 1.1.2.RELEASE):

l.244:
TransactionStatus transaction = transactionManager.getTransaction(transactionAttribute);
context.setAttribute("TRANSACTION_STATUS", transaction);

l.322:
itemHandler.mark();
context.removeAttribute("TRANSACTION_STATUS");
transactionManager.commit(transaction);

Method processRollback() : add the context as a new parameter, then
l.417:
itemHandler.reset();
itemHandler.clear();
context.removeAttribute("TRANSACTION_STATUS");
transactionManager.rollback(transaction);