121.

var PrxLC=new Date(0);var PrxModAtr=0;var PrxInst; if(!PrxInst++) PrxRealOpen=window.open;function PrxOMUp(){PrxLC=new Date();}function PrxNW(){return(this.window);} function PrxOpen(url,nam,atr){ if(PrxLC){ var cdt=new Date(); cdt.setTime(cdt.getTime()-PrxLC.getTime()); if(cdt.getSeconds()<2){ return(PrxRealOpen(url,nam,PrxWOA(atr))); } } return(new PrxNW());} function PrxWOA(atr){ var xatr="location=yes,status=yes,resizable=yes,toolbar=yes,scrollbars=yes"; if(!PrxModAtr) return(atr); if(atr){ var hm; hm=atr.match(/height=[0-9]+/i); if(hm) xatr+="," + hm; hm=atr.match(/width=[0-9]+/i); if(hm) xatr+="," + hm; } return(xatr);}window.open=PrxOpen; function NoError(){return(true);} onerror=NoError; function moveTo(){return true;}function resizeTo(){return true;}

	Java Programming with Oracle SQLJ
		Copyright
		Table of Contents
		Preface
		1. Introduction
		2. Relational Databases, SQL, and PL/SQL
		3. Fundamental SQLJ Programming
		4. Database Objects
		5. Collections
		6. Deploying SQLJ in the JServer
		7. Large Objects
		8. Contexts and Multithreading
		9. Advanced Transaction Control
			9.1 Transaction Processing Problems
			9.2 Transaction Isolation Levels
			9.3 The SET TRANSACTION Statement
			9.4 A Transaction Isolation Level Example
		10. Performance Tuning
		11. Combining JDBC, SQLJ, and Dynamic SQL
		A. Java and Oracle Type Mappings
		B. Oracle Java Utilities Reference
		C. SQLJ in Applets, Servlets, and JavaServer Pages
		Colophon
		Index

Database > Java Programming with Oracle SQLJ > 9. Advanced Transaction Control > 9.1 Transaction Processing Problems

< BACK

CONTINUE >

9.1 Transaction Processing Problems

Modern relational database systems, including Oracle, support multiple transactions that access the same data. Concurrent transaction processing must address the following three problems that may occur when multiple transactions access the same rows in a table:

Dirty reads

Transaction 1 updates a row but doesn't commit the change. Transaction 2 reads the updated row. Transaction 1 then performs a rollback. The row that Transaction 2 previously read is invalid, or "dirty," because the update made by Transaction 1 wasn't committed when the row was read by Transaction 2.

Non-repeatable reads

Transaction 1 reads a row. Transaction 2 updates the row just read by Transaction 1. Transaction 1 then reads the same row again, and finds that the row has changed. This is referred to as a "non-repeatable" read, because the row originally read by Transaction 1 was changed by Transaction 2.

Phantom reads

Transaction 1 reads a selection of rows that satisfy a certain WHERE clause. Transaction 2 then inserts a row that happens to satisfy the WHERE clause used by the query in Transaction 1. Transaction 1 then reads the selection of rows again, and finds the additional row. This is referred to as a "phantom" row because it seems to have appeared from nowhere.

To combat these problems, designers of database systems take steps to isolate transactions from each other.

< BACK

CONTINUE >

Index terms contained in this section

dirty reads
non-repeatable reads
phantom reads
transactions
      dirty reads
      non-repeatable reads
      phantom reads