Data consistency is a term used to describe the accuracy of data. For example, suppose you have a table that maintains a count of vehicles available for sale in car dealerships. When a vehicle is transferred from dealership A to dealership B, the count has to decrease in dealership A and increase in dealership B. Both actions must take place; if one occurs and another does not, the data becomes inaccurate—data inconsistency occurs.

Data inconsistency can occur due to several factors:
1. Data is accessed/updated by multiple users at the same time
2. Transition fails to perform all necessary actions due to a crash
To prevent the occurrence of the above situations, a DBMS (database management system) relies on isolation levels and locks.

The following databases have default transaction isolation level as TRANSACTION_READ_COMMITTED.

SQL SQL Server 2005 Books Online
Controlling Transactions and Locks in SQL 2000 and 2005 – Part 1

Data Concurrency and Consistency
Ask Tom:On Transaction Isolation Levels

Distributed DBA: DB2 Isolation Levels–Beyond The Default -part 1
Distributed DBA: DB2 Isolation Levels–Beyond The Default -part 2
Database Isolation Levels

Spring Transaction management: here

Update: 01-16-2008
Java JDBC Transaction Isolation Levels
Generally speaking, as the isolation levels become more restrictive, the performance of the system decreases because transactions are prevented from accessing the same data. If isolation levels are very restrictivein other words, if they are at the Serializable levelthen all transactions, even simple reads, must wait in line to execute. This can result in a system that is very slow. J2EE server that process a large number of concurrent transactions and need to be very fast will therefore avoid the Serializable isolation level where it is not necessary.

Read Uncommitted The transaction can read uncommitted data (i.e., data changed by a different transaction that is still in progress). Dirty reads, nonrepeatable reads, and phantom reads can occur. Bean methods with this isolation level can read uncommitted changes.

Read Committed
The transaction cannot read uncommitted data; data that is being changed by a different transaction cannot be read. Dirty reads are prevented; nonrepeatable reads and phantom reads can occur. Bean methods with this isolation level cannot read uncommitted data.

Repeatable Read
The transaction cannot change data that is being read by a different transaction. Dirty reads and nonrepeatable reads are prevented; phantom reads can occur. Bean methods with this isolation level have the same restrictions as those in the Read Committed level and can execute only repeatable reads.

The transaction has exclusive read and update privileges; different transactions can neither read nor write to the same data. Dirty reads, nonrepeatable reads, and phantom reads are prevented. This isolation level is the most restrictive.

Note: J2EE Isolation level on connections used by CMP beans
In a EJB 2.x or EJB 3.0 module, when a CMP bean uses a new data source to access a backend database, the isolation level is determined by J2EE Application Server run time, based on the type of access intent assigned to the bean or the calling method. Other non-CMP connection users can access this same data source and also use the access intent and application profile support to manage their concurrency control.

Choose optimal isolation level
Example: JDBC Transaction Isolation Levels
Isolation levels and concurrency