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.

[Daniel Morgan]

neo wrote:

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.

Why are you letting anyone, or any thing, read an uncommited
transaction? If it is not committed ... it doesn't exist.
--
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)

[neo]

Daniel Morgan <da******@x.was hington.edu> wrote in message news:<106912243 4.507152@yasure >...

neo wrote:

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.

Why are you letting anyone, or any thing, read an uncommited
transaction? If it is not committed ... it doesn't exist.

This function sets dirty-read enable.
So even though there is blocking,
with this connection, data can still be read. That's what I want.

[rkusenet]

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

neo wrote:

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.

Why are you letting anyone, or any thing, read an uncommited
transaction? If it is not committed ... it doesn't exist.

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.

Oracle's MVRC sounds great, but unless it gives an option
to bypass when it is unnecessary, it is an overkill.

rk-

[Daniel Morgan]

rkusenet wrote:

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

neo wrote:

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

setTransacti onIsolation(Con nection.TRANSAC TION_READ_UNCOM MITTED)

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
setAutoCommi t(false) 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.

Why are you letting anyone, or any thing, read an uncommited
transaction ? If it is not committed ... it doesn't exist.

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.

Oracle's MVRC sounds great, but unless it gives an option
to bypass when it is unnecessary, it is an overkill.

rk-

Makes sense but if you only do READ_UNCOMMITTE D on old data why not just
partition it?

My concern is that while some might use this as you describe ... others
could just as easily produce invalid reports. There is no protection in
the system to protect the end-user. How do they know?
--
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

Makes sense but if you only do READ_UNCOMMITTE D on old data why not just
partition it?
why an oracle like approach for everything :-) U asked a question whether
READ_UNCOMMITTE D has any value, I gave one and I can give many more
examples like this where a particular ISOLATION mode may be appropriate.

Oracle's assumption that its MVRC is best for all situations is plain
horse manure. They should give the flexibility to the developers to
use appropriate ISOLATION mode. I use it in Informix and SQLSERVER and
I am very happy with these products (atleast on this count) which gives
me the flexibility.

My concern is that while some might use this as you describe ... others
could just as easily produce invalid reports. There is no protection in
the system to protect the end-user. How do they know?

well, I am using ur own words of wisdon. Learn to work in SQLSERVER as
it is suppose to work, not like Oracle :-). I expect SQLSERVER developrs
to have an understanding of ISOLATION level.

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 in message news:1069122434 .507152@yasure. ..

neo wrote:

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.

Why are you letting anyone, or any thing, read an uncommited
transaction? If it is not committed ... it doesn't exist.

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"?

Cheers,
Dave

Oracle's MVRC sounds great, but unless it gives an option
to bypass when it is unnecessary, it is an overkill.

rk-

[Dave Hau]

One concern I have with uncommitted/dirty read is that documentation says
that "this is the lowest level where transactions are isolated only enough
to ensure that physically corrupt data is not read". This is not enough to
guarantee row-level read consistency, meaning you might not get data of the
same version for all columns, particularly for columns which have BLOB or
CLOB types for which the data is typically stored in another page.

- Dave

"Dave Hau" <nospam_dave_no spam_123@nospam _netscape_nospa m.net_nospam> wrote
in message news:SM******** ***********@new ssvr27.news.pro digy.com...

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

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

neo wrote:

> 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.

Why are you letting anyone, or any thing, read an uncommited
transaction? If it is not committed ... it doesn't exist.

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"?

Cheers,
Dave

Oracle's MVRC sounds great, but unless it gives an option
to bypass when it is unnecessary, it is an overkill.

rk-

[Dave Hau]

"neo" <se*******@hotm ail.com> wrote in message
news:15******** *************** **@posting.goog le.com...

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.
When compared with READ COMMITTED, did you get more or same or less blocking
using READ UNCOMMITTED? Maybe your updates and inserts by themselves
already generate a lot of blocking, irrespective of your reads. This can
happen say for example if you run low on memory and SQL Server starts
locking pages instead of rows.

Another suggestion I can think of is update your JDBC driver to the latest
version.

HTH,
Dave

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.

[Dave Hau]

"Dave Hau" <nospam_dave_no spam_123@nospam _netscape_nospa m.net_nospam> wrote
in message news:SM******** ***********@new ssvr27.news.pro digy.com...

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

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

neo wrote:

> 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.

Why are you letting anyone, or any thing, read an uncommited
transaction? If it is not committed ... it doesn't exist.

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"?
Never mind. I see - because of the overhead of the single read lock when
you use READ_COMMITTED. My bad.

- Dave


Cheers,
Dave

Oracle's MVRC sounds great, but unless it gives an option
to bypass when it is unnecessary, it is an overkill.

rk-