> An excellent question. Yes, something like that could be done, but
> let's look at the ramifications. First, that would require that
> every server process maintain a separate connection to the shadow
> server (not a bad name; somebody will probably want to change to
> show he's paying attention; you should always pick a bad name
> first). This complicates the shadow server.

Or you change the way you connect to the server. TCP is currently the
only option that people start thinking about, but they forgot the full
family of group communication protocols that use UDP multicast
(unreliable protocol) to reliably deliver information to multiple
nodes without requiring separate connection to them.

Does it work? Yes. In years 2001-2003 I relatively actively
participated in development of JavaGroups toolkit (now JGroups, part
of JBoss.org "project", thing that stays behind their clustering
packages). The speed to distribute "messages" to multiple nodes using
the UDP stack is higher than same approach using the TCP stack.

JGroups is not the only implementation, there's few others, old ones
like Horus and Ensemble and new ones - Tribe (currently part of Tomcat).

> On the other hand, if the shadow server is going
> shadow more than one database, maybe that's unavoidable. Second, to
> guarantee database integrity, the protocol would have to sequence
> messages.

Automatically guaranteed by the protocol stack - you specify only the
required properties (FIFO, Total Ordering).

> This would require that the shadow server return an
> acknowledgment to the database engine that the page message had been
> accepted before the page lock could be down graded.

This schema has performance issues - usually an NACK is used - when
node detects a hole in packets, it sends the message back.

> Finally, the database
> attachment process in classic would require a hand shake with the
> shadow server, slowing that down too.

Ok, here it is the same - joining the group is expensive. The only
possible solution - join it and stay connected.

> Yes, it could be done. But doing it in classic would cripple the
> performance of the superserver.

I tell you one more schema - the Linda language family / tuple spaces
to which classics connect via IPC and it then sequentially sends pages
to shadow server. Also preservs the ordering.

Roman