|Subject||Re: Remote Shadows (again...)|
> An excellent question. Yes, something like that could be done, butOr you change the way you connect to the server. TCP is currently the
> 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.
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 goingAutomatically guaranteed by the protocol stack - you specify only the
> shadow more than one database, maybe that's unavoidable. Second, to
> guarantee database integrity, the protocol would have to sequence
required properties (FIFO, Total Ordering).
> This would require that the shadow server return anThis schema has performance issues - usually an NACK is used - when
> acknowledgment to the database engine that the page message had been
> accepted before the page lock could be down graded.
node detects a hole in packets, it sends the message back.
> Finally, the databaseOk, here it is the same - joining the group is expensive. The only
> attachment process in classic would require a hand shake with the
> shadow server, slowing that down too.
possible solution - join it and stay connected.
> Yes, it could be done. But doing it in classic would cripple theI tell you one more schema - the Linda language family / tuple spaces
> performance of the superserver.
to which classics connect via IPC and it then sequentially sends pages
to shadow server. Also preservs the ordering.