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

32
CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS
The theoretical advantage of the first approach is that to move from database to database
you need not change anything. I call it a “theoretical” advantage because the downside of this
implementation is so huge that it makes this solution totally infeasible. What you would have
to do to develop a totally database-independent process is to create a table such as
ops$tkyte@ORA10G> create table id_table
2 ( id_name varchar2(30) primary key,
3 id_value number );
Table created.
ops$tkyte@ORA10G> insert into id_table values ( 'MY_KEY', 0 );
1 row created.
ops$tkyte@ORA10G> commit;
Commit complete.
Then, in order to get a new key, you would have to execute the following code:
ops$tkyte@ORA10G> update id_table
2 set id_value = id_value+1
3 where id_name = 'MY_KEY';
1 row updated.
ops$tkyte@ORA10G> select id_value
2 from id_table
3 where id_name = 'MY_KEY';
ID_VALUE
----------
1
Looks simple enough, but the outcomes (notice plural) are as follows:
• Only one user at a time may process a transaction row. You need to update that row to
increment a counter, and this will cause your program to serialize on that operation. At
best, one person at a time will generate a new value for this key.
• In Oracle (and the behavior might be different in other databases), all but the first user
to attempt to concurrently perform this operation would receive the error “ORA-08177:
can’t serialize access for this transaction” in the SERIALIZABLE isolation level.
For example, using a serializable transaction (which is more common in the J2EE environment,
where many tools automatically use this as the default mode of isolation, often
unbeknownst to the developers), you would observe the following behavior. Notice that the
SQL prompt (using the SET SQLPROMPT SQL*Plus command) contains information about which
session is active in this example: