READ_UNCOMMITTE D problem with SQL 2000 and i-net Opta 2000 JDBC

[neo]

Hi,
I have a problem to set a JDBC connection as READ UNCOMMITED.

setTransactionI solation(Connec tion.TRANSACTIO N_READ_UNCOMMIT TED)

This is causing lots of blocking on tables
and update or insert doesn't work properly.

Does anyone have any idea what I'm missing here?

I asked i-net support and they suggested to call
setAutoCommit(f alse) after the above function
and it didn't work.
also suggested impltrans = true, and I changed that option on SQL
and it caused more blocking.

Thanks in advance for any info.

[rkusenet]

"Dave Hau" <nospam_dave_no spam_123@nospam _netscape_nospa m.net_nospam> wrote

ah.. this is a typical oracleisque response. Well there are
some circumstances when READ_UNCOMMITTE D makes perfect sense.
For e.g. if u r running report on past data (like last week's report)
which is guaranteed to be read-only at the time of running
the report. why bother about COMMITTED data? a simple dirty
read will do the job as effectively, but more efficiently.

Unless you're running low on memory and getting lock escalation from row to
page lock, I don't see why your past data (assuming you don't update past
data) will have a lock on them. If there's no lock, then why would there be
a difference between doing READ_UNCOMMITTE D and READ_COMMITTED on those
rows. If there's no difference, then why did you say READ_UNCOMMITTE D will
do the job "more efficiently"?

actually I should have been clearer.
the more efficiently part was in comparison to oracle's MVRC approach,
not a one to one comparison between SQLSERVER RC and RUC approach.

Even within SQLSERVER RC and RUC, RUC is slightly more efficient since
it does not have to put a read lock on a row.

RUC vs MVRC is all together different. In MVRC it has to check for
every page whether the SCN is less than the SCN when the query started,
a totally unnecessary step for the case in question.

[Daniel Morgan]

rkusenet wrote:

<snipped>

RUC vs MVRC is all together different. In MVRC it has to check for
every page whether the SCN is less than the SCN when the query started,
a totally unnecessary step for the case in question.

True. But on the other hand it doesn't have to check to see if the
row is locked. Because in the Oracle world it would be irrelevant.
Writes don't block reads and reads don't brock writes.

All RDBMS's have over-head issues. They are always there ... they are
just different.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[rkusenet]

"Daniel Morgan" <da******@x.was hington.edu> wrote in message news:1069192733 .974181@yasure. ..

rkusenet wrote:

<snipped>

RUC vs MVRC is all together different. In MVRC it has to check for
every page whether the SCN is less than the SCN when the query started,
a totally unnecessary step for the case in question.

True. But on the other hand it doesn't have to check to see if the
row is locked.

That is in RC and SER only.
RUC does not check whether the row is locked and for the case in
question, RUC is best.
Because in the Oracle world it would be irrelevant.
Writes don't block reads and reads don't brock writes.

oracle does not give any flexiblity in writing the application as
required. It forces MVRC always. In Informix I use RC, RUC and
SER as they are required on a case to case basis. Now I follow
the same priciple in SQLServer also.

I am not denying that MVRC is good. All I am disputing is that
it is DA best for every situation, as Oracle arrogantly assumes.
Clearly it isn't.

I believe SQLServer is implementing MVRC in Yukon. That's great,
since they will still be offering RC,RUC and SER. Oracle should also
do that.

rk-

[Daniel Morgan]

rkusenet wrote:

"Daniel Morgan" <da******@x.was hington.edu> wrote in message news:1069192733 .974181@yasure. ..

rkusenet wrote:

<snipped>

RUC vs MVRC is all together different. In MVRC it has to check for
every page whether the SCN is less than the SCN when the query started,
a totally unnecessary step for the case in question.

True. But on the other hand it doesn't have to check to see if the
row is locked.

That is in RC and SER only.
RUC does not check whether the row is locked and for the case in
question, RUC is best.

Because in the Oracle world it would be irrelevant.
Writes don't block reads and reads don't brock writes.

oracle does not give any flexiblity in writing the application as
required. It forces MVRC always. In Informix I use RC, RUC and
SER as they are required on a case to case basis. Now I follow
the same priciple in SQLServer also.

I am not denying that MVRC is good. All I am disputing is that
it is DA best for every situation, as Oracle arrogantly assumes.
Clearly it isn't.

I believe SQLServer is implementing MVRC in Yukon. That's great,
since they will still be offering RC,RUC and SER. Oracle should also
do that.

rk-

Arrogantly is no more a constructive phrase when referring to MVCC than
would be the same statement with respect to SQL Server's inability to
run on a UNIX platform. Lets leave the hyperbole to the marketing
departments where it belongs.

Then visit this link:
http://download-west.oracle.com/docs...6a.htm#2067250

and notice the graphic a few inches from the bottom of the first page.
The one that contains SET TRANSACTION. See anything that might make you
reconsider the depth of your knowledge of Oracle?
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[rkusenet]

"Daniel Morgan" <da******@x.was hington.edu> wrote

Then visit this link:
http://download-west.oracle.com/docs...6a.htm#2067250

and notice the graphic a few inches from the bottom of the first page.
The one that contains SET TRANSACTION. See anything that might make you
reconsider the depth of your knowledge of Oracle?

I never claimed that I am an expert in Oracle. Indeed I would have worked
less than six months of my career in Oracle. My information about MVRC
is based on what oracle marketing literature.

However it gives me a good idea on the depth of ur knowledge
as a database teacher in Washingto Univ if u make a stupid
and false claim that reading uncommitted data is useless under
all circumstances. I proved it isn't.

Now that we both have insulted each other, can u come to the
point. Does oracle allow applications to bypass MVRC. I could
have gone to the above link, but it requires a registered login.

thanks.
rk-

[Dave Hau]

"rkusenet" <rk******@sympa tico.ca> wrote in message
news:bp******** *****@ID-75254.news.uni-berlin.de...

"Daniel Morgan" <da******@x.was hington.edu> wrote

Then visit this link:
http://download-west.oracle.com/docs...6a.htm#2067250
and notice the graphic a few inches from the bottom of the first page.
The one that contains SET TRANSACTION. See anything that might make you
reconsider the depth of your knowledge of Oracle?
I never claimed that I am an expert in Oracle. Indeed I would have worked
less than six months of my career in Oracle. My information about MVRC
is based on what oracle marketing literature.

However it gives me a good idea on the depth of ur knowledge
as a database teacher in Washingto Univ if u make a stupid
and false claim that reading uncommitted data is useless under
all circumstances. I proved it isn't.

Now that we both have insulted each other, can u come to the
point. Does oracle allow applications to bypass MVRC. I could
have gone to the above link, but it requires a registered login.

I think what rk is talking about is whether Oracle ever allows you to read a
block without checking its SCN.

SET TRANSACTION READ ONLY and SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
use transaction-level read consistency, whereas SET TRANSACTION READ WRITE
and SET TRANSACTION ISOLATION LEVEL READ COMMITTED use statement-level read
consistency. The bottom line is these all require checking the SCN of every
block that you read, comparing its SCN to the SCN of either the beginning of
statement execution, or the beginning of the transaction, and rolling back
the data if necessary. AFAIK, there's no mechanism in Oracle to read a
block without checking its SCN, although SCN checking is basically only an
integer comparison, and even though you're doing it for every block read, I
don't think it represents any significant overhead compared to the time it
takes to actually read the block.

- Dave


thanks.
rk-

[rkusenet]

"Dave Hau" <nospam_dave_no spam_123@nospam _netscape_nospa m.net_nospam> wrote

I think what rk is talking about is whether Oracle ever allows you to read a
block without checking its SCN.
correct. just like Read Uncommitted allows reading a row without checking
for anything.

SET TRANSACTION READ ONLY and SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
use transaction-level read consistency, whereas SET TRANSACTION READ WRITE
and SET TRANSACTION ISOLATION LEVEL READ COMMITTED use statement-level read
consistency. The bottom line is these all require checking the SCN of every
block that you read, comparing its SCN to the SCN of either the beginning of
statement execution, or the beginning of the transaction, and rolling back
the data if necessary. AFAIK, there's no mechanism in Oracle to read a
block without checking its SCN, although SCN checking is basically only an
integer comparison, and even though you're doing it for every block read
So I was right.
I don't think it represents any significant overhead compared to the time it
takes to actually read the block.

In real world applications, YMMV.

rk-

[Daniel Morgan]

Comments in-line

rkusenet wrote:

"Daniel Morgan" <da******@x.was hington.edu> wrote

Then visit this link:
http://download-west.oracle.com/docs...6a.htm#2067250

and notice the graphic a few inches from the bottom of the first page.
The one that contains SET TRANSACTION. See anything that might make you
reconsider the depth of your knowledge of Oracle?

I never claimed that I am an expert in Oracle. Indeed I would have worked
less than six months of my career in Oracle. My information about MVRC
is based on what oracle marketing literature.

Good lord man. I hope you don't buy or use any product, not even a
dish washer basedon marketing literature.
However it gives me a good idea on the depth of ur knowledge
as a database teacher in Washingto Univ if u make a stupid
and false claim that reading uncommitted data is useless under
all circumstances. I proved it isn't.
Don't mean to be insulting here but perhaps you should re-read my posts,
I never said reading uncommitted data was useless. Dangerous perhaps but
not useless: Never used the word.
Now that we both have insulted each other, can u come to the
point. Does oracle allow applications to bypass MVRC. I could
have gone to the above link, but it requires a registered login.

If by bypass you mean transactions that don't use it? Yes! But if you
think that means dirty reads ... no.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

Comments inline.

rkusenet wrote:

"Dave Hau" <nospam_dave_no spam_123@nospam _netscape_nospa m.net_nospam> wrote

I think what rk is talking about is whether Oracle ever allows you to read a
block without checking its SCN.
correct. just like Read Uncommitted allows reading a row without checking
for anything.

This is an impossible question to answer. Because you can not ever read
a block (in SQL Server verbiage page) without reading the SCN as it is
stored in the block. You can't read something and not read part of it.
Even if you wanted to the operating system would ignore you. Sort of
like asking MS Word to open a document but not read the document's font
information.

But if you mean not use multiversion concurrency with the SCN to
determine whether the row has been changed yes you can.

SET TRANSACTION READ ONLY and SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
use transaction-level read consistency, whereas SET TRANSACTION READ WRITE
and SET TRANSACTION ISOLATION LEVEL READ COMMITTED use statement-level read
consistency . The bottom line is these all require checking the SCN of every
block that you read, comparing its SCN to the SCN of either the beginning of
statement execution, or the beginning of the transaction, and rolling back
the data if necessary. AFAIK, there's no mechanism in Oracle to read a
block without checking its SCN, although SCN checking is basically only an
integer comparison, and even though you're doing it for every block read

So I was right.

No you weren't. I'd suggest you stop spending so much energy trying to
be correct and use this as an opportunity to learn something. You may
well end up on a project some day that requires knowledge of more than a
single RDBMS. I, for example, am currently working in Oracle, Informix,
SQL Server, MS Access, and FoxPro between a variety of projects.

I don't think it represents any significant overhead compared to the time it
takes to actually read the block.

It takes zero extra time because it is part of the block. If a block is
8K then part of that 8K is the SCN information.

In real world applications, YMMV.

rk-

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Dave Hau]

"Daniel Morgan" <da******@x.was hington.edu> wrote in message
news:1069217819 .771457@yasure. ..

Comments inline.

rkusenet wrote:

"Dave Hau" <nospam_dave_no spam_123@nospam _netscape_nospa m.net_nospam> wrote

I think what rk is talking about is whether Oracle ever allows you to read ablock without checking its SCN.
correct. just like Read Uncommitted allows reading a row without checking for anything.

This is an impossible question to answer. Because you can not ever read
a block (in SQL Server verbiage page) without reading the SCN as it is
stored in the block. You can't read something and not read part of it.
Even if you wanted to the operating system would ignore you. Sort of
like asking MS Word to open a document but not read the document's font
information.

But if you mean not use multiversion concurrency with the SCN to
determine whether the row has been changed yes you can.
SET TRANSACTION READ ONLY and SET TRANSACTION ISOLATION LEVEL SERIALIZABLEuse transaction-level read consistency, whereas SET TRANSACTION READ WRITEand SET TRANSACTION ISOLATION LEVEL READ COMMITTED use statement-level readconsistency . The bottom line is these all require checking the SCN of everyblock that you read, comparing its SCN to the SCN of either the beginning ofstatement execution, or the beginning of the transaction, and rolling backthe data if necessary. AFAIK, there's no mechanism in Oracle to read a
block without checking its SCN, although SCN checking is basically only aninteger comparison, and even though you're doing it for every block read

So I was right.

No you weren't. I'd suggest you stop spending so much energy trying to
be correct and use this as an opportunity to learn something. You may
well end up on a project some day that requires knowledge of more than a
single RDBMS. I, for example, am currently working in Oracle, Informix,
SQL Server, MS Access, and FoxPro between a variety of projects.

I don't think it represents any significant overhead compared to the time ittakes to actually read the block.

It takes zero extra time because it is part of the block. If a block is
8K then part of that 8K is the SCN information.

Daniel, I think what rk is talking about is whether Oracle ever allows you
to read a block without *checking* its SCN, not just reading the SCN. Of
course, you're right - when you read a block, you read the SCN as well. But
he's talking about the extra step of checking the SCN against the SCN at the
beginning of the statement execution (for statement level read consistency)
or the SCN at the beginning of the transaction (for transaction level read
consistency) to determine if you need to roll back the block.

Regards,
Dave

In real world applications, YMMV.

rk-

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)