SEO

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

setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)

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

neo wrote:

> Hi,
> I have a problem to set a JDBC connection as READ UNCOMMITED.
>
> setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
>
> 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(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.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1069122434.507152@yasure>...
> neo wrote:
>
> > Hi,
> > I have a problem to set a JDBC connection as READ UNCOMMITED.
> >
> > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> >
> > 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(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.

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.

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1069122434.507152@yasure...
> neo wrote:
>
> > Hi,
> > I have a problem to set a JDBC connection as READ UNCOMMITED.
> >
> > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> >
> > 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(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_UNCOMMITTED 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-

rkusenet wrote:

> "Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1069122434.507152@yasure...
>
>>neo wrote:
>>
>>
>>>Hi,
>>>I have a problem to set a JDBC connection as READ UNCOMMITED.
>>>
>>>setTransactionIsolation(Connection.TRANSACTION_ READ_UNCOMMITTED)
>>>
>>>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(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_UNCOMMITTED 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_UNCOMMITTED 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
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

"Daniel Morgan" <damorgan@x.washington.edu> wrote

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

why an oracle like approach for everything :-) U asked a question whether
READ_UNCOMMITTED 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-

"rkusenet" <rkusenet@sympatico.ca> wrote in message
news:bpdm0b$1nhu6v$1@ID-75254.news.uni-berlin.de...
>
> "Daniel Morgan" <damorgan@x.washington.edu> wrote in message
news:1069122434.507152@yasure...
> > neo wrote:
> >
> > > Hi,
> > > I have a problem to set a JDBC connection as READ UNCOMMITED.
> > >
> > > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> > >
> > > 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(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_UNCOMMITTED 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_UNCOMMITTED and READ_COMMITTED on those
rows. If there's no difference, then why did you say READ_UNCOMMITTED 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-
>
>
>

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_nospam_123@nospam_netscape_nospam.net _nospam> wrote
in message news:SMvub.33830$sk4.10816@newssvr27.news.prodigy. com...
> "rkusenet" <rkusenet@sympatico.ca> wrote in message
> news:bpdm0b$1nhu6v$1@ID-75254.news.uni-berlin.de...
> >
> > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message
> news:1069122434.507152@yasure...
> > > neo wrote:
> > >
> > > > Hi,
> > > > I have a problem to set a JDBC connection as READ UNCOMMITED.
> > > >
> > > > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> > > >
> > > > 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(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_UNCOMMITTED 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_UNCOMMITTED and READ_COMMITTED on those
> rows. If there's no difference, then why did you say READ_UNCOMMITTED
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-
> >
> >
> >
>
>

"neo" <second714@hotmail.com> wrote in message
news:155f8e7d.0311171747.939d534@posting.google.co m...
> Hi,
> I have a problem to set a JDBC connection as READ UNCOMMITED.
>
> setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
>
> 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(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.

"Dave Hau" <nospam_dave_nospam_123@nospam_netscape_nospam.net _nospam> wrote
in message news:SMvub.33830$sk4.10816@newssvr27.news.prodigy. com...
> "rkusenet" <rkusenet@sympatico.ca> wrote in message
> news:bpdm0b$1nhu6v$1@ID-75254.news.uni-berlin.de...
> >
> > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message
> news:1069122434.507152@yasure...
> > > neo wrote:
> > >
> > > > Hi,
> > > > I have a problem to set a JDBC connection as READ UNCOMMITED.
> > > >
> > > > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> > > >
> > > > 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(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_UNCOMMITTED 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_UNCOMMITTED and READ_COMMITTED on those
> rows. If there's no difference, then why did you say READ_UNCOMMITTED
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-
> >
> >
> >
>
>