Is Spring a Transaction Manager?

[javamq]

For an upcoming project, I will be updating multiple databases in a txn (2PC). My plan is to use JTA and WebSphere as the TM.

My questions are:

1. Is Spring a TM? Can Spring act as the TM ? If so, I do not need WebSphere and can achieve 2PC with just Spring+Tomcat. Somehow, I doubt Spring can do this. All vendors would be out of business otherwise.

2. If Spring is not a TM, why should I use it's transaction framework? Why should I use org.springframework.transaction.jta.JtaTransaction Manager when I could use JTA directly ?

Thanks in advance.

[irbouho]

1. No.
2. Spring Declarative Transaction Demarcation makes it very easy to apply transaction management to POJOs.
Also, it is very easy to switch between Jta and DataSource Transaction management (scale-up, scale-down, Unit testing).

[javamq]

<quote>
it is very easy to switch between Jta and DataSource Transaction management (scale-up, scale-down, Unit testing).
</quote>

Can you kindly elaborate? What do you mean by switching between JTA and Datasource? Do you really mean switching between JTA and JDBC (conn.setAutocommit(false) mechanism) ? Also, how would Spring make unit testing any easier if I were to use JTA txn. mgmt ?

[irbouho]

it is very easy to switch between Jta and DataSource Transaction management

You can develop your application using org.springframework.jdbc.datasource.DataSourceTran sactionManager and deploy it, as it is, to let's say tomcat. If you need JtaTransaction, it is a matter of configration, switch your configuration to use org.springframework.transaction.jta.JtaTransaction Manager and you are done. Spring abstrats transactions management from Business Layer. You no longer need to code against a specific Transaction API.

how would Spring make unit testing any easier if I were to use JTA txn. mgmt

Generaly, you use DataSourceTransactionManager for development Unit/Testing as you don't want to deploy the entire application to the J2EE server to test a class method. Spring makes Unit Testing easier by allowing developpers to use a light weight environment for development/testing.When Unit test succeed, just switch to JtaTransactionManager and deploy your application to J2EE server for integration tests.

[javamq]

Thanks very much, Omar. Your prompt response is very much appreciated.

In order to be able to switch between JTA approach and Datasource approach, I *must* use declarative txn. mgmt throughout, correct ?

[irbouho]

In order to be able to switch between JTA approach and Datasource approach, I *must* use declarative txn. mgmt throughout, correct ?

You should be able to use org.springframework.transaction.support.Transactio nTemplate for programmatic transaction management with a transaction manager that implements PlatformTransactionManager (HibernateTransactionManager, DataSourceTransactionManager, JTATransactionManager).
For more details, take a look at Spring javadoc.

[javamq]

After reading parts of the reference manual and the javadoc on the txn api, the only value proposition I find is the synchronization/callback mechanism where Spring provides me hooks to guard against erroneous TM implementations or to include non-XA resources into my own poor man's 2PC system.

Other than that, I still fail to find a compelling reason to use Spring. The ability to test using Datasource txn. manager during Unit testing and switching to JTA in production does not apply in my case, since my unit tests need to test updates involving multiple databases (2PC), hence I have to use JTA.

Either I am missing the whole picture or I suspect people are getting carried away with the whole "declarative xml" approach.

[robh]

I would consider the tests across multiple datasources to be more integration tests rather than unit tests. Surely you will be testing each individual component in isolation from the rest of the system.

Reading between the lines from your post it seems that you are planning on not using EJB and using the JTA APIs directly. This is where Spring offers you substantial benefits. Not only can you take advantage of the DI framework - but at the same time you can declartively configure which methods should use JTA transactions. For instance you may create a method foo() on your service object which in turn calls Dao1.bar() and Dao2.bar() to insert into multiple databases. Doing this by hand means coding all the JTA interactions in the foo() method AND getting it right. Using Spring just simply say "Make foo() transactional and use JTA".

Rob

[javamq]

Ah yes, declarative txn. mgmt WITHOUT using EJBs is a good value provided by Spring.

However, a userTxn.begin() at the start and a userTxn.commit()/rollback at the end is not too much to ask for. I would rather do that instead of throwing yet another layer of software into the mix, especially when it comes to the murky world of transactions.

[trisberg]

Can you kindly elaborate? What do you mean by switching between JTA and Datasource? Do you really mean switching between JTA and JDBC (conn.setAutocommit(false) mechanism) ?

Yes, that is one of the advantages of using Spring's transaction abstraction. You can use he same business logic code in both a JTA environment and in a single datasource JDBC transaction environment. The only change is in your configuration file. Spring does act as a transaction manager in a single datasource environment by keeping the connection in a thread local. The framework code will check for an ongoing transaction and will participate if there is one. In the case of a JTA transaction environment the framework code will automatically particpate here as well. This is a great advantage if you ever have to run code outside of your appservers JTA environment.

Spring also allows you to declare nested transactions if you are in a single datasource environment (using JDBC 3 savepoints) - this is something that you can't do in a JTA environment. You can also specify which exceptions should cause a rollback and which should not - you don't have to limit yourself to RuntimeException even if that is the default.