Transactions in Enterprise level application

Question

I am trying to understand the transactions, and more specifically i am doing it using Spring framework. Going through the material that i have (both internet and books), i see these terminologies:

1. Container managed transactions (CMT).
2. Bean Managed transactions (BMT).
3. Java transaction API (JTA).

Also, for a large enterprise level application, terminologies like "local" and "global" transactions too i have encountered.

What i have understood, is that global transactions is for the cases in which we are managing two or more different resouces (like One Oracle DB, other MySQL etc) and commits/rollback to them happen if both are success/failure. Local transactions is for when we have only one resource to manage (like only one DB connection to MySQL).

I have following doubts:

1. While writing a simple JDBC standalone program, we can code to commit/rollback. I believe this is example of local transaction, is this correct? And is this transaction taken care by "JDBC" library itself or the drivers?

2. What is CMT? What i understand is that Container takes care of the transaction management (like Jboss AS). If this is correct, how internally does it manages? Are CMT local or global? Do they use JDBC API's internally to manage the transactions?

3. What is BMT? This i am not able to understand. We can have application deployed in an App server (and i believe in those cases the transaction would be managed by Container) or i can write an standalone application in which i can use the transaction management code myself (try .. catch block etc). So, which category BMT falls?

4. While reading Spring framework, i read that Spring framework have its own way of managing the transaction. Down the line, i read Spring Framework uses JTA to manage transactions? I am confused about this. If JTA is API, do we have multiple vendors who implement JTA (like for JPA, we can have multiple vendors who provide the implementation e.g. Hibernate).

5. Is JTA for local or global transactions? When i write a simple JDBC program to manage transaction, does it use API's which comply JTA? Or is JTA totally different from transaction management which simple JDBC program uses?

6. Same for CMT, does CMT follow the rules which JTA has in place (the API's primarily)?

It would be great if you answer point-wise, i did search on net, my doubts are still not answered.

Answer 1

Concerning local/global transaction: by global I suppose you are talking about XA transaction (2 phase commits : http://en.wikipedia.org/wiki/X/Open_XA). This is just mandatory when you deal with multiple databases or transactionnal resources.

1. yes it's a "local transaction", it means only one database is part of the transaction. The transaction is managed by the database and controlled by JDBC in that case.

2. CMT : Container Managed: the container will detect the start and the end of the transaction and will perform commit/rollback depending on method return status (successfull return : commit, exception : rollback). CMT rely on JTA to manage transactions on its resources. Then it's up to the proper resource adapters (RA) to talk to jdbc or any other drivers related to your EIS (data). Look at http://docs.oracle.com/javaee/5/tutorial/doc/bncjx.html

3. BMT: it means it's up to the bean to control transaction boundaries. It's pretty rare to use this kind of transaction management these days. With BMT you control the UserTransaction object, it's an error to control transaction boundaries directly with JDBC. Bear in mind also that even if you are in BMT some framework like JPA (not JTA) will invalidate current transaction on any error even if you did not explicitely requested a rollback. It means it's quite hard/dangerous/useless to use BMT.

4. JTA (I hope you did not mispelled JPA) is at another level: JTA the API a resource adapter must implement to be part of a container transaction. Apart from UserTransaction class (what you'll use in BMT to control transaction boundaries) you have nothing to do with JTA. There is no multiple implementation of JTA but there is multiple implementation of JTS (Java Transaction Service), each application server vendor implements their own JTS.

5. JTA is a API for framework designer, JTA impose a contract to the Resource Adapter RA, and the RA will use JDBC or any other API to deal with it's EIS (Enterprise Information Storage, let's call it your DB). JTA works for XA and non XA transactions (if your RA supports XA transactions).

6. CMT uses JTA, but again JTA is a lowlevel contract between components of the application server. Application designer should not care about JTA.