How does one manage concurrency issues with JDBC?

Joe Sam Shirah

JDBC is based on ISO-ANSI SQL, which provides for database concurrency using isolation levels. These are defined to deal with the "phonema" of dirty reads, non-repeatable reads and phantom inserts. "The four isolation levels guarantee that each SQL-transaction will be executed completely or not at all, and that no updates will be lost." While almost all programs will be concerned with dirty reads, in the real world we probably want to use and see the most current data, so non-repeatable reads and phantom inserts may not be an issue. Here's a table that briefly summarizes what the defined isolation levels guarantee:

Isolation Level Dirty Read Non-Repeatable Read Phantom Insert
Read Uncommitted Possible Possible Possible
Read Committed Not Possible Possible Possible
Repeatable Read Not Possible Not Possible Possible
Serializable Not Possible Not Possible NotPossible

In JDBC, the isolation level is set by Connection.setTransactionIsolation(int level) with the default being auto-commit. Note that a particular database may not support all isolation levels ( DatabaseMetaData.supportsTransactionIsolationLevel(int) will validate a particular isolation level. ) Also, isolation level is a Connection property; this means that it applies to all Statements created by a Connection, and that a commit or rollback also applies to all Statements.

A complete explanation could take a several chapters in a book, so take a look at Where can I find online documentation for database xyz? for more information.

Finally, isolation levels are more concerned with data integrity in the face of concurrent transactions, than with allowing concurrent access for many users of the database.