Why should you use SimpleJTA

There are some obvious and some not so obvious reasons for using a product like SimpleJTA.

Obvious Reasons

Portability.

Your application needs to run outside a J2EE application server. Perhaps it needs to run in a servlet container like Tomcat. But you want your code to portable so that it can be moved from a Tomcat implementation to a J2EE implementation. In this scenario, you can use SimpleJTA in the Tomcat environment to make your code portable. By using the J2EE UserTransaction interface, your code will work correctly when you deploy it under J2EE.

Distributed Transactions.

You application requires the ability to commit transactions across multiple databases, and you are running your application outside of a J2EE application server.

Not so obvious reasons

In the old days of 2-tier client server applications, where the client had all the business logic, and the server was usually the database, life was easy and simple. The client application could acquire a connection to the database, and this connection would be dedicated for the client, so the client would hold on to it, and carry out various transactions. At the end the client would release the connection to the database.

The situation is not so simple these days. In the world of web applications, and the 4-tier architecture (browser, servlet, application, database) that it entails, one of the key design concerns is to separate out the presentation layer (servlets) from the business logic (application) layer, and the business logic (application) layer from the database layer. This means that the presentation layer does not know anything about the database layer.

In a complex situation, the interaction between the presentation layer, the business logic layer, and the database layer may look like this:

Of course, it is not always as complex as this. In many simple applications, the presentation layer probably calls one business logic component, which in turn invokes one dao component.

In the complex case depicted above, there are multiple calls being made by the presentation layer to the business logic layer. Also, the business logic layer is making multiple calls to the database layer. Because only the database layer knows about the database, each time it is called, it must acquire a database connection, perform its work, and then close it. Of course, the connection will be obtained from a connection pool, so the overhead of obtaining a new connection and closing it is not really that large.

The main point to note in this scenario is that without the UserTransaction facility, there is no way that the presentation layer can manage the whole process as a single transaction. If we did not have the UserTransaction facility, each Dao invocation would have to be a transaction, or we would have break the rules of separating concerns into layers, and allow the connection object to be visible to the presentation layer, and let it be managed by the presentation layer. Obviously, not a desirable solution.

The UserTransaction interface provides us the ability to transactionalize our work in this complex situation. But that is not all. If you are using a single database, then the UserTransaction implementation can be optimised so that it does not perform 2-phase commits. Instead, all it does is provide you the connection object (it should be designed to give you the same connection object each time) and the transaction is actually committed as one-phase just as it would have been if you had invoked commit() on the connection yourself. In this situation, you also do not require crash recovery support because, by definition, a one-phase transaction is immediately resolved by the database manager. Therefore, transaction logging will not be used, and performance will be comparable to locally managed transactions.