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 | 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. |
Index terms contained in this section dirty reads non-repeatable reads phantom reads transactions dirty reads non-repeatable reads phantom reads | |