Arno Brinkman wrote:

>I beleive there was argument that a Cluster environment can only work on
>Classic?
>
>

Good question.

Signals and threads are in general a bad mix, like drinking and driving
or thinking and using Powerpoint. A cluster implementation does require
the classic behavior (it was designed for clusters in the first place
and worked just fine, thank you). But I'm not at all sure than classic
behavior can't be implemented cleanly in a multi-threaded environment.
The essence of classic behavior is that page locks are retain while a
page is in cache unless a block AST is received, at which point either
the lock is downgraded or a note is made to downgrade the lock when page
is no longer in active use. Assuming the posix threads and signals
co-exist (painful story here), there should be no problem.

On the other hand, I don't think a particularly strong argument can be
made for the cluster architecture for database systems, and I'm not
convinced that tradeoffs should be made to preserve this capability. If
it's almost free, sure, keep the academics happy.

>Okay, what are your ideas of implementing garbage removing in the current
>architecture? Immediatly garbage collect page before storing to disk?
>
>

I was thinking of the editor delete command.

Among the problems with the garbage collect thread it increases total
system activity (systems that do more work go more slowly) and the
failure to do timely garbage collections can have a major adverse effect
on performance.

The only idea behind garbage collection thread is that an innocent
reader shouldn't be charged for cleanup after large update transaction.
But the work has to be done and the sooner the better.

Ann's measurements showed a dramatic increase in system performance by
killing the garbage collect thread.

>>What am I missing?
>>
>>
>
>Time :-)
>
>
>