At 06:18 PM 9/7/00 -0400, Chaim Frenkel wrote:
> >>>>> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>
>AB> Chaim Frenkel wrote:
> >> The problem I have with this plan, is reconciling the fact that a
> >> database update does all of this and more. And how to do it is a known
> >> problem, its been developed over and over again.
>
>AB> I'm sorry, but you are wrong. You are confusing transactions with
>AB> threading, and the two are fundamentally different. Transactions are
>AB> just a way of saying 'I want to see all of these changes, or none of
>AB> them'. You can do this even in a non-threaded environment by
>AB> serialising everything. Deadlock avoidance in databases is difficult,
>AB> and Oracle for example 'resolves' a deadlock by picking one of the two
>AB> deadlocking transactions at random and forcibly aborting it.
>
>Actually, I wasn't. I was considering the locking/deadlock handling part
>of database engines. (Map row -> variable.)
The problem with using database locking and transactions as your model is
that they're *expensive*. Amazingly so. The expense is certainly worth it
for what you get, and in many cases the expense is hidden (at least to some
extent) by the cost you pay in disk I/O, but it's definitely there.
Heavyweight locking schemes are fine for relatively infrequent or expensive
operations (your average DLM for cluster-wide file access is an example)
but we're not dealing with rare or heavy operations. We're dealing with
very lightweight, frequent operations. That means we need a really cheap
locking scheme for this sort of thing, or we're going to be spending most
of our time in the lock manager...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
