recommendations for writing a new transaction manager with custom commit/rollback logic

Question

I wish to write a transaction manager which support multi-db and best effort commit logic. Shall I base it from Spring's AbstractPlatformTransactionManager or javax.transaction.TransactionManager or something else?

I have existing applications which use Spring's JpaTransactionManager and DataSourceTransactionManager and an internal customized CustomTransactionManager.

My goal is to provide a single transaction manager to all my Java applications so that i can offer/control common transactional features. My requirement is not 2PC but i need multi data source support with best effort commit (transaction manager notifies application of commit failures and onus is on application to handle the situation by retrying failed queries).

I have been reading about Spring's PlatformTransactionManager, its implementations Jpa and Datasource Transaction managers. Checked JTA/XA implementation provided in SimpleJta which is based on javax.transaction.xa package classes.

When i consider requirement of easy integration with existing applications, Spring's AbstractPlatformTransactionManager looks like a good base class for new transaction manager. On the other hand, javax.transaction.xa package provides some simple abstractions for managing connection resources with in a transaction. May be if i can implement single phase commit with javax.transaction, it'll work.

My question is : going with Spring framework's AbstractPlatformTransactionManager is better or using javax.transaction and integrate it with Spring applications would be good?

I expect to write easily integrate-able (with existing spring based apps), simple and maintainable component.

Apologies if question is too vague. I am still reading through options and i might not have complete understanding of spring and javax.transaction.

Answer 1

I wish to write a transaction manager which support multi-db and best effort commit logic.

There are sound reasons why this isn't a common Thing. You probably shouldn't try to make it a Thing until you understand what those are.

If you need guarantees that your application's transactions will recover after an outage, including a server crash, then Full XA is your only choice.

That's... Wrong. It's true that is you need full ACID guarantees then XA is pretty much your only choice for interoperable tx involving databases. However e.g. WS-AT is a perfectly good ACID transaction protocol for web based resource managers.

ACID transactions are not the whole story though. For saga type transactions you need some form of compensation framework that provides lifecycle callbacks to the application. WS-BA and the more recent microprofile LRA specs work in this area.

So, your choice is roughly: (mis)use XA with e.g. last resource commit optimization, multiple last resources, or other weakened guarantees and hope the JTA API is flexible enough, or just jump direct to a saga based tx API that's tailored for the job.

I expect to write ... simple and maintainable component.

Regardless of which transaction model you choose, DO NOT attempt to write your own transaction manager for it from scratch. Distributed transaction coordination is full of tricky corner cases and building a correct and robust engine is a lot harder than it first appears. Leverage one of the mature existing open source transaction managers instead.

Narayana provides full ACID XA out of the box, but can be configured to provide best-effort under the JTA API if you really want it. (Hint: you don't) It also has saga support via the WS-BA and LRA specs if you prefer to go that route. The only credible competitor with a comparable feature set outside a full JakaraEE app server is Atomikos. Spring itself is NOT a distributed transaction manager implementation, it's a API that delegates to one.

Answer 2

If you need guarantees that your application's transactions will recover after an outage, including a server crash, then Full XA is your only choice. The shared resource that is used to synchronize the transaction in this case is a special transaction manager that coordinates information about the process using the XA protocol. In Java, from the developer's point of view, the protocol is exposed through a JTA UserTransaction.

If the application is Spring-enabled, it uses the Spring JtaTransactionManager and Spring declarative transaction management to hide the details of the underlying synchronization. The difference for the developer between using XA and not using XA is all about configuring the factory resources: the DataSource instances, and the transaction manager for the application. The DataSource instances and the transaction manager are the only XA- or JTA-specific elements of the application.

Please see this artical transaction rollback with multiple datasources, this will make you more understanding distibuted transaction Spring with and without XA (https://www.javaworld.com/article/2077963/distributed-transactions-in-spring--with-and-without-xa.html)