Mohammed Amine TAZI is a Sun Certified Enterprise Architect and J2EE developer. He's passionate about J2EE technology and learning foreign languages. Mohammed Amine is a DZone MVB and is not an employee of DZone and has posted 4 posts at DZone. View Full User Profile

J2EE Transactions Explained

09.13.2010
| 10585 views |
  • submit to reddit

Enterprise applications use different resources to save data and send messages like a database or message queue. If we want to query these resources sequentially and to cancel the whole operation once a problem occurs, we have to put this query in a unit of work so that will be executed as a whole.

To make it clear, taking for example a customer that wants to sign up for a premium account in your site and he will wait 2 days to get his account activated once payment is received. Suppose that there is a problem in payment, the right choice is  not to register the user until you get paid. These 2 operations should be executed both or cancelled both. So here we englobe these 2 operations in a transaction.

Transaction properties :

These properties are known by the ACID acronym. Each letter stands for a property :

  1. Atomicity : means that the whole operations are executed as a whole (all or nothing rule). This is what I explained in the example above.
  2. Consistency : Data must be consistent in the beginning as well as the end of the transaction.
  3. Isolation : When we have concurrent access to data, operations cannot access modified data in the current transaction.
  4. Durability: Once the transaction finished, modified data must not be lost and should be the same afterward.

Transaction types :

  • Global transactions

These type of transactions are needed when dealing with multiple resources (database, message queue..). In order to use global transactions, Java Transaction API (JTA) is needed and it’s available only in an application server environment

  • Local transactions

Unlike global transactions, local transactions are used to deal with a single resource as a JDBC connection for a single database. Normally it’s easier to use than global transactions.

Transaction propagation :

It refers to what happens to a transaction when a method calls another method. Suppose we have method signup() calling method sendEmail().

Required :

  • signup() holds a transaction T1 à sendEmail() uses transaction T1.
  • Signup() doesn’t hold a transaction à sendEmail() creates a new transaction T1.

Requires New :

  • Signup() holds a transaction T1 à sendEmail() creates a new transaction T2.
  • Signup() doesn’t hold a transaction à sendEmail() creates a new transaction T1.

Supports :

  • signup() holds a transaction T1 à sendEmail() uses transaction T1.
  • Signup() doesn’t hold a transaction à sendEmail() doesn’t hold a transaction.

Not Supports :

  • signup() holds a transaction T1 à sendEmail() doesn’t hold a transaction.
  • Signup() doesn’t hold a transaction à sendEmail() doesn’t hold a transaction.

Mandatory :

  • signup() holds a transaction T1 à sendEmail() uses transaction T1.
  • Signup() doesn’t hold a transaction à Exception is thrown.

Never :

  • signup() holds a transaction T1 à Exception is thrown.
  • Signup() doesn’t hold a transaction à sendEmail() doesn’t hold a transaction.

Nested :

  • signup() holds a transaction T1 à sendEmail() creates a nested transaction inside T1 like a savepoint. This is applied only to JDBC resources.
  • Signup() doesn’t hold a transaction à sendEmail() creates a new transaction T1.

Transaction Isolation levels :

Isolation is the behavior of rendering data once accessed concurrently within a transaction.

Bellow are the isolation levels that differ in implementation for every resource.

  • Read Committed : it ensures that data modifications in a transaction are not read until the transaction commits.
  • Read uncommitted : unlike “Read Committed” level, data modifications are read during a transaction even if the transaction can be rolled back later. It’s called also “Dirty Read”.
  • Repeatable read: it ensures that data will not be modified by another transaction so as data is consistent when reading it during different times of a transaction.
  • Serializable : it ensures data is not inserted or updated until the transaction finishes.
From http://www.misterj2ee.com/2010/09/j2ee-transactions-explained/
Published at DZone with permission of Mohammed Amine Tazi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Byju Veedu replied on Mon, 2010/09/13 - 4:07am

Muhammed,

         A very good summary. There used to have confusion about the difference B/w requires new and nested.This wikipedia link will be very usefull to understand nested transactions http://en.wikipedia.org/wiki/Nested_transaction

 

Mohammed Amine Tazi replied on Mon, 2010/09/13 - 4:14am in response to: Byju Veedu

Thank you Byju. The link that you provided is instructive and can help either.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.