Olivier Mascia wrote:

>Dear,
>
>Thanks for this article on how WAL was originally designed.
>
>
>

You're more than welcome.

I think studying the success/failure of major sub-projects can go a long
way towards avoiding future, er, challenges.

Among the more significant problems of the WAL from my perspective:

1. It's theoretical implications weren't well understood
2. The design was complex with tentacles in a hundred modules
3. It had to work from the beginning, meaning a minor problem was
catestrophic from a system perspective
4. It required a fundamental change in the way the system was
supposed to operate without corresponding change to the engine
architecture.

In Vulcan, I'm trying very hard to avoid these problems. My strategy is:

1. Restore the architecture and integrate DSQL
2. Revert (more or less) to classic, a known simple and reliable
configuration
3. Disable (but not remove) all existing thread synchronization code
4. Put RW locks on all critical and gateway objects.
5. Put RW locks on the BDB (buffer descriptor blocks)

Except for step 1, in which I am now painfully mired, the process is
intended to procede without ever breaking the engine for more than a few
minutes, at least when running with a single thread. I always like to
work by making tiny incremental changes checking frequently that the
beast still works.

Happily, I don't have to change the way the engine works or the way the
engine is structured at all. It's absolutely fine as is. The fact that
classic is careful write and deadlock free means that a smattering of RW
locks in critical places alone with a frame local synchronization class
to automatically release locks on "block" exit is all that is necessary
to keep threads from interfering with each other.


[Non-text portions of this message have been removed]