Able to make dirty read using Oracle 9i and JDBC thin driver v 9.2.0

Question

I've searched this forum and did not see anything to directly answer my question.
I checked the Oracle JDBC Frequently Asked Questions...
ditto (perhaps due to the fact that it was last updated: 22 June 2001).
So here is my question, and thank you in advance for any insight (apologies if I have missed finding an already answered question):
Section 19-15 of:
"JDBC Developer’s Guide and Reference"
(which is for Oracle 9i database)
downloadable from:
http://download-east.oracle.com/docs/cd/B10501_01/java.920/a96654.pdf
is entitled:
"Transaction Isolation Levels and Access Modes"
The section seems to indicate that
if JDBC connection A is setup with:
setAutoCommit(false)
setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED)
and then used to perform an update on a row (no commit(), rollback(), or close() yet) ...
then JDBC connection B (setup in the same way) will be prevented from
making a dirty read of that same row.
While this behavior (row-level locking) occurs correctly when using MS SQL Server 2000,
it is not occuring correctly with Oracle 9i and the Oracle Thin JDBC driver version 9.2.0.
The test case I have shows that with Oracle, connection B is able to make a dirty read
successfully in this case.
Am I doing something wrong here ?
Again, MS SQL Server correctly blocks connection B from making the Read until Connection A
has been either committed, rolled back, or closed, at which time connection B is able to
complete the read because the row is now unlocked.
Is there a switch I must throw here ?
Again, any help is greatly appreciated.

Answer 1

Thanks for the response.
I understand what you are saying...
that readers don't block writers in Oracle (the same is true in SQL Server 2000).
However, I don't see how my test case is working correctly with Oracle (the exact same code acting as I'm thinking it should with SQL Server, but I still think it is acting incorrectly with Oracle).
I have transaction A do this:
update <table> set <column2>=<value> where <column1>='1'
then I use Thread.sleep() to make that program hang around for a few minutes.
Meanwhile I sneak off and start another program which begins transaction B. I have transaction B do this:
select * from <table> where <column1>='1'
and the read works immediately (no blocking... just as you have said) however, transaction A is still sleeping, it has not called commit() or rollback() yet.
So what if transaction A were to call rollback(), the value read by transaction B would be incorrect wouldn't it ?
Both A and B use setAutoCommit(false) to start their transactions, and then call setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED).
Isn't that supposed to guarantee that a reader can only read what is committed ?
And if a row is in "flux"... in the process of having one or more values changed, then the database cannot say what the value will be ?
I can almost see what you are saying.
In letting the reader have what it wants without making it wait, I suppose it could be said that Oracle is holding true to the "only let committed data be read"
So if that's it, then what if I want the blocking ?
I want an entire row to be locked until whoever it in the middle of updating, adding, or removing it has finished.
Do you know if that can be done with Oracle ? And how ?
Thanks again for helping me.