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