Re: Changing isolation level? ++ scenarios

rgaffuri_at_cox.net (Ryan Gaffuri) wrote in message

> > The bottom line IMO is information. Provide the business with
> > information in order for them to make their decisions. Isolation
> > levels are not an issue - not if you use Oracle correctly and not if
> > you design your app & database correctly.
>
>
> oh wait, when you query the data, cant you also query the transaction
> number on the rows involved? then check that against the transaction
> number at the time of performing DML? This will probably involve
> hitting v$ views, so you need to test for latch contes ntion. Not sure
> how else forms would manage this... and if forms does it, then its
> doable.

Whoa. I never mentioned v$ views or anything remotely like that.

What I am saying is that this thread is jumping the gun about technical issues and perceived problems WITHOUT knowing *what* business requirements to meet (as sketched in the scenario).

Fact. If two or more users want to access the exact same piece of data, there will be serialisation.

Business requirements will state the when and why this is needed. The technical challenge is how to do it - using minimal serialisation. That challenge is met by database design and app design. Not hacking Oracle internals like v$ views to make it work.

Some more rambling on this issue...

Rigid db design and strict adherance to formal design methodologies is IMO stupid. You make it fit your needs instead of trying to fit your needs to it.

Simple example. Rewind. 80's. Transactions on inserting & selecting invoices from a database, given the business volume, exceeds the i/o capability of the mainframe platform. Upgrading the mainframe is not an option due to cost. What do you? You denormalise the invoice header & invoice line tables into a single 2nd normal form table and change an average of 18 logical i/o's per invoice into a single logical i/o.

Not purist? Right. But a real world solution for real world problem. Ditto for the technical problems raised in this sales-product-inventory scenario.

But *before* going down the merry technical path and isolation levels, a *clear* problem definition is needed with a *clear* requirement specification. And IMO hacking isolation levels in context of the scenario given is not needed - you design the db and app to cater for these challenges instead.

--
Billy