Re: How to update multiple rows atomically

paul c wrote:

But I'll ramble on anyway. Personally, I've found that users are fine
with apps that very occasionally time out because of races or simple
contention. They don't find this unreasonable as long as invoking a
retry isn't onerous, which the app designers can cater for and as long
as they don't have to undo partial work, which the dbms should cater for.
[...]
Sometimes I think it is just undisciplined ego, "because it's there",
that drives people to make a problem that needs to be solved out of
every phenomenon whereas I think some problems are meant to be avoided,
not solved, like certain back alleys late at night. There's lots that
RT is silent about and that's okay by me - it's about a model for
handling data, not a prescription for a modelling language. After all,
RT is silent about disk head seek times too.

Well Paul I hear you, but I'm not satisfied with that approach.
Maybe it is ego on my part, but dammit I want to do better
than I have been doing, and I want to drag as many people
as possible up with me. If code has a race condition or
a deadlock or whatever in it, I won't settle for anything less
than that being a compile time error, or a proof that that's
impossible.

If I was happy with practicality *merely* I'd still be slinging
C++ or whatever, content with knowing that debuggers are
getting better. The thing that attracts me to the RM is not
the practicality of it, although that is certainly nice, but the
long-term potential of building on a solid foundation. That's
the sort of thing that makes it possible to leapfrog the
current state of the art for what's practical.

I guess I have to expand the scope of the model to include
not just data management but concurrency and distribution.
Sigh.


Marshall

.

Relevant Pages