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