> -----Original Message-----
> From: Olivier Mascia [mailto:om@...]
> Sent: Sábado 26 de Agosto de 2000 2:38
>
> Case B) Single Server accessing a remote database :
> Why not implement it by having the server mark something identifying it
> _inside_ the DB while readying it (its network name, its IP,
> something else
> ?).

But if the server dies, you have to clear the flag manually, as you
suggested at the tail of your letter, with gfix. Now, do we need that gfix
is able to touch remote databases through a share to disable the flag?

> Case C) Multi-servers accessing a shared remote database
> I do not see this as a clear advantage, and I'd favor dropping this idea.
>
> 1) Though regarding the issue of lock manager, one idea could be
> to make the
> servers coordinates together. That is : having server B talk to
> Server A for
> any locking requests. If the server is alone, see Case B). If another one
> jumps online, it engages on a collaborative lock management with
> the initial
> server.
>
> 2) Another idea. If Case B) implemented, when a second (third,...) server
> tries to ready the database which is already under the control of another
> server, why not implement a 'redirection' mechanism from server B
> to server

This seems like an extension to the current protocol that allows one IB
server to pass the request to a second IB server. This is an old capability,
but I only discovered that recently, in September 1999, while playing with
the IB6 in private beta testing, when I connected through IBConsole in the
form
server:localhost:disk:/path/db.gdb
and there wasn't a complain at connect time. I was indeed connected to the
server but I couldn't execute any SQL command against tables.

C.