Re: Article about supposed "murky" future for Oracle

"rkusenet" <rkusenet_at_sympatico.ca> wrote in message news:<c4ffjh$2hpu17$1_at_ID-75254.news.uni-berlin.de>...
> "Serge Rielau" <srielau_at_ca.eye-be-em.com> wrote
>
>
> the other way to put this is that application has to be designed
> accordingly. In a properly designed system, such exaggerated scenarios
> of read-blocking-writes rarely happens or can be completely eliminated.

so your recent posting in another newsgroup trying to figure out why a simple query in read committed isolation is deadlocking with other statements was due to an improperly designed system?

or that you must commit really frequently (like row by row) when doing a mass purge to avoid the "long transaction problem" is good design? -- another posting of your recently.

You are right -- if you get paid by the hour, and you like to write tons of code, blocking reads, inconsistent reads -- they are really good ideas. I concurr.

if you want it right, want it fast, want it without thinking about how concurrent reads and writes would be done......

the real problem is that many (i might even say most) developers don't understand concurrency control. they have no idea that they need repeatable read/serializable. they don't understand the ramifications of using/not using it (well, i take that back -- they know if they use RR or serializable things seem to go "bad" -- deadlocks, blocks -- so they avoid it like the plague).

that "well designed" part is something that seems to be 'rare' (else there would not be so many postings I suspect in the other groups about these issues)

>
> This is what I call as marketing hype. Present a scenario about competing
> products as if it is insurmountable.

It can be insurmountable (did you ever figure out why that simple query deadlocks -- I cannot even imagine having to worry about such a thing. how many hours were spent by you and others looking at that problem. How happy are the endusers when they get "sorry your query failed due to a deadlock") -- or the attempts to get around it so expensive as to be laughable. the general solution in other RDBMS -- lets have a reporting instance so we avoid this (how many sqlserver -- both flavors, informix installations have I seen with this "solution" - yeah, we just need another database, thats the ticket)

> Of course Oracle is not the only one to do it. IBM seems to be learning fast,
> as evident in this
>
> http://www-3.ibm.com/software/data/pubs/papers/readconsistency/readconsistency.pdf
Received on Thu Apr 01 2004 - 08:18:09 CST