Subject | Re: [Firebird-Architect] Remote Shadows (again...) |
---|---|
Author | Jim Starkey |
Post date | 2006-10-04T13:46:49Z |
Alexandre Benson Smith wrote:
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. 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. 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 would be a
significant performance hit, both from the requirement for a round trip
per page and the additional latency of the round trip. The superserver
alternative streams data on an open socket. Finally, the database
attachment process in classic would require a hand shake with the shadow
server, slowing that down too.
Yes, it could be done. But doing it in classic would cripple the
performance of the superserver.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
> Jim Starkey wrote:An excellent question. Yes, something like that could be done, but
>
>> I haven't a clue as to how to do it in classic. The superserver version
>> would probably take less than a week to implement included the server.
>>
>>
> Sorry if this is just stupid, but in classic there is a point where the
> page is written to disk, two process can't write a single page ate the
> same time right ?
> Why this same piece of code doesn't write to disk and send the page
> content to the "shadow server" over the wire ?
>
>
>
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. 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. 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 would be a
significant performance hit, both from the requirement for a round trip
per page and the additional latency of the round trip. The superserver
alternative streams data on an open socket. Finally, the database
attachment process in classic would require a hand shake with the shadow
server, slowing that down too.
Yes, it could be done. But doing it in classic would cripple the
performance of the superserver.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376