05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

192<br />

CHAPTER 6 ■ LOCKING AND LATCHING<br />

7 end;<br />

8 /<br />

PL/SQL procedure successfully completed.<br />

which we can see is currently<br />

ops$tkyte@ORA10G> select :deptno dno, :dname dname, :loc loc, :last_mod lm<br />

2 from dual;<br />

DNO DNAME LOC LM<br />

---------- ---------- -------- -----------------------------------<br />

10 ACCOUNTING NEW YORK 25-APR-05 10.54.00.493380 AM -04:00<br />

it would use this next update statement to modify the information. The last line does the very<br />

important check to make sure the timestamp has not changed <strong>and</strong> uses the built-in function<br />

TO_TIMESTAMP_TZ (TZ is short for TimeZone) to convert the string we saved in from the select<br />

back into the proper datatype. Additionally, line 3 of the update updates the LAST_MOD column<br />

to be the current time if the row is found to be updated:<br />

ops$tkyte@ORA10G> update dept<br />

2 set dname = initcap(:dname),<br />

3 last_mod = systimestamp<br />

4 where deptno = :deptno<br />

5 <strong>and</strong> last_mod = to_timestamp_tz(:last_mod);<br />

1 row updated.<br />

As you can see, one row was updated—the row of interest. We updated the row by primary<br />

key (DEPTNO) <strong>and</strong> verified that the LAST_MOD column had not been modified by any other session<br />

between the time we read it first <strong>and</strong> the time we did the update. If we were to try to<br />

update that same record again, using the same logic, but without retrieving the new LAST_MOD<br />

value, we would observe the following:<br />

ops$tkyte@ORA10G> update dept<br />

2 set dname = upper(:dname),<br />

3 last_mod = systimestamp<br />

4 where deptno = :deptno<br />

5 <strong>and</strong> last_mod = to_timestamp_tz(:last_mod);<br />

0 rows updated.<br />

Notice how 0 rows updated is reported this time because the predicate on LAST_MOD was<br />

not satisfied. While DEPTNO 10 still exists, the value at the moment we wish to update no longer<br />

matches the timestamp value at the moment we queried the row. So, the application knows,<br />

based on the fact that no rows were modified, that the data has been changed in the database—<br />

<strong>and</strong> it must now figure out what it wants to do about that.<br />

You would not rely on each application to maintain this field for a number of reasons. For<br />

one, it adds code to an application, <strong>and</strong> it is code that must be repeated <strong>and</strong> correctly implemented<br />

anywhere this table is modified. In a large application, that could be in many places.<br />

Furthermore, every application developed in the future must conform to these rules. There are<br />

many chances to “miss” a spot in the application code <strong>and</strong> not have this field properly used.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!