>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The problem with using database locking and transactions as your
DS> model is that they're *expensive*. Amazingly so. The expense is
DS> certainly worth it for what you get, and in many cases the expense
DS> is hidden (at least to some extent) by the cost you pay in disk
DS> I/O, but it's definitely there.
I lost you. How is the model wrong? Perl has a resource, Databases
have a resource. Perl does a V or P operation, so does a Database.
DS> Heavyweight locking schemes are fine for relatively infrequent or
DS> expensive operations (your average DLM for cluster-wide file
DS> access is an example) but we're not dealing with rare or heavy
DS> operations.
Even databases have to handle this problem. The granularity of the
locking. Row vs. page vs. Table (might be other schemes I don't know enough)
DS> We're dealing with very lightweight, frequent
DS> operations. That means we need a really cheap locking scheme for
DS> this sort of thing, or we're going to be spending most of our time
DS> in the lock manager...
The issue is correctness. Lightweight Heavyweight has no meaning to me.
How does Lightweight and Heavyweight map to correctness. And what
is a lightweight and what is a heavyweight.
We haven't yet even discussed the implementation details, we have been
waving our hands, moving between the language layer and implementation
layer.
One thing to consider, what do to about Deadlocks and the notification
and recovery method. Without a rollback mechanism, each and every
programmer will have to roll their own. So we either provide it or we
have to make it easy for them to recover from a major blow. (Unless
you are going to simply let the threads sit in deadlock until a human
or watchdog timer kills the entire process)
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
