Case A) Single Server accessing local database : available today.

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
?).
Other servers, if they try to ready that database will discover it is
already readied by another server and will abort their attempt. No need for
over the net locking mechanism.

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
A. Two possibilities : let the clients continue talking to server B, but
this ones delegates all requests to server A. B clients talk to B server,
but B server does nothing except relaying to A server. The other brute idea
is equivalent to the HTTP-REDIRECT. Client connects to B, request access to
a database. B discover database is already readied by server A and reply to
the client : "kindly reconnect to server A, which is the current handling
unit for that DB".

That's brute ideas, for sure.
But the Case C) point 2) appeals to me.
I consider that trying to have 2 or more servers access a shared database
somewhere is NOT the way to achieve better performance or load balancing.
I suppose the main issue/need here is simply to have the Case B) : for some
reasons, I need ONE server to access a remote database (because I can't for
any reason have the files local). Then, all we need is a solution that
securely blocks multiple servers to access the same remote DB. Case C) 2)
combined with Case B) may be a very simple solution.

One new option in GFIX should be needed to be able to clean the
'reservation' a server will make _in_ the database when readying it. In case
of crash or problems, someone can clear the ownership of the DB and let
another server take on the role.

-------------------------- www.tipgroup.com -------------------------
Olivier Mascia T.I.P. Group S.A.
om@... Company Phone +32 65401111
Director, Senior Software Engineer Private Mailbox/FAX +32 27065653