CODEWITHSUNDEEP
javajakarta-eejta
sam
sam

Reputation: 83

Transaction in Java EE or distributed transaction

I'm a beginner in Java EE and I'm developing a web application which has lots of database operations. I'm confused about transactions in Java EE.

My problem is that I'm using Tomcat and I don't know about the types of transactions in Java EE, but I have to use them on my project. So, I have searched many times for it and got so many "kides" of that:

  1. Using connection.setAutoCommit(false), but it is connection managed?

  2. Using Javax.Transaction.UserTransaction

What are the differences between these two, and is there any other way?

I'm using NetBeans 7.0 and Tomcat is integrated with it. When I try to use javax.transaction.UserTransaction it's unable to autocomplete this interface, but is does gives a suggestion for java.transaction.xa;

so what should i do???

Note: I can't use EJB because Tomcat is the web server that is provided to me by the hosting server.

Upvotes: 2

Views: 2116

Answers (2)

Pace
Pace

Reputation: 43817

As you pointed out. There are many meanings of the word "transaction". One popular meaning is a database transaction.

  • A database transaction is a collection of database operations that are atomic (either all succeed or all fail), consistent (the database must be valid before and after the transaction), isolated (other transactions may not see changes until the transaction is complete), and durable (once committed a transaction is persisted).

These transaction can be managed at the connection level, typically with connection.setAutoCommit(false), connection.commit(), and connection.rollback().

The other kind of transaction you have found is the JTA transaction. A JTA transaction is a very abstract concept and simply surrounds a "set of operations". By itself, JTA does nothing with transactions. Typically however, people will plug JTA resource managers which do something when transactions start or finish.

For example, someone could setup a messaging resource manager to make sure JMS messages are only sent out when a transaction is committed. Someone could also use a database resource manager to start and stop the database transaction (descried above) when the JTA transaction is started and stopped.

JTA has a significant configuration overhead and can be quite a bit of work to setup. It is usually only used when you need to manage a cluster of resources (e.g. a cluster of databases) and coordinate among them.

If you have only a single database then you can get away with using transactions on JDBC directly. If you are using something on top of JDBC (e.g. JPA) then these tools will often manage your transactions for you.

A popular approach is to use Spring managed transactions. Spring is similar to JTA in that it has a very generic definition of transaction but it is quite a bit easier to configure. Going with Spring has two distinct advantages. The first is that they're transaction demarcation (using the @Transactional annotation) is sometimes a lot easier than dealing with commit and rollback (don't need to have quite so many try/catch/finally statements). Another reason is that if you end up moving to a cluster you can always plug in JTA beneath Spring later on.

Upvotes: 2

polemoser
polemoser

Reputation: 59

By default there is no container managed transaction in Tomcat - in this situation you have to handle transactions in the same way as you do in Java SE. This has nothing to do with EE, therefore you can not use the javax.transaction.UserTransaction.

Upvotes: 0

Related Questions