= m. Th = wrote:

> No, is solved. If we implement this by allowing the fbclient.dll to send
> /simultaneously/ the commands to all nodes. A intresting thing which I
> see now though is the time to switch to another node/connection thread
> and continue fetching data from there when the fbclient kills the main
> connection thread due to 'unable to connect to host' error. But I wait
> the opinion from the developers.
>

Hi,

I have read your proposal, really don't know how feasible it is (I am
not arguing against *your* proposal, but the "behind the scenes work"
that pass my superficial knowledge about FB).

A point I can't understand is how /simultaneously/ would be achieved.
I understand that the fbclient will have a connection to each node and
send the same statement (insert, update, delete, DDL, selects don't need
to go to each one, but just one that will answer the query) , this need
to be atomic, an statement should only be considered committed once it
goes to all nodes, if a node fail, how it will be rolled back on the
others (two-phase commit ?), or once one of the nodes couldn't be
reached it will just be marked as outdated ?

Another question, now talking about distributed nodes using a gateway
(AFAIU this is the way you suggest distributed nodes should be used)

If it will be marked as outdated, how frequent will be all nodes be
marked as oudated ?

On time T1 host in Brazil could not be reached by the gateway, so it
will be marked as outdated
On time T2 host in Canada could not be reached by the gateway, so it
will be marked as outdated
On time T3 host in "Your office" could not be reached by the gateway, so
it will be marked as outdated

Another question will be:
If I have a node on my Branch in Brazil, my traffic should go to the
gateway on France, that will connect to my node in Brazil get the
response back, while I could reach it inside my LAN (the same for the
other branches), lookslike an overkill to me.

But for fault tolerance and all hosts on the same LAN segment (or
connected by extremelly fast and reliable links), I understand it could
work.

Another point:
Even if the connections are really fast and all hosts on the same LAN
the order of propagation of the updates by the fbclient to all hosts is
fixed ?
Let's take this scenario running simultaneously:

T1 = Transaction 1, T2 Transaction 2, C1 = Client 1, N1 = Node 1 and so on.

C1 - T1 - Insert into Children (ParentID) (1) on N1; (ok)
C2 - T2 - Delete from Parent where ParentID = 1 on N2; (ok)
C1 - T1 - Insert into Children (ParentID) (1) on N2; (fail FK dependence)
C2 - T2 - Delete from Parent where ParentID = 1 on N1; (fail FK dependence)

Let's suppose that for some unknown reason the DELETE statement from
C2-T2 runs faster on N2 than on N1 the statement only will be considered
"done" when all nodes send a sucessfull response ? The rollback would be
handled automagically on the "sucessfull" nodes by the client ? Node 1
will not send an error to C1 - T1 in INSERT neither Node 2 will send an
error to C2-T2 on the DELETE.

Did I get it wrong ?

> Usually the Firebird is very fast. Perhaps you can expose your problem
> (with queries, configuration aso.) in firebird-support group. The main
> goal of clustering in my implementation isn't to achieve a throughput
> improvement.
>

Eduardo is a very experienced FB developer (from the user point of view,
instead of core FB developer). I don't know the specific performance
problem they are talking about, but I can guess he is talking about
distributed branches across the country and a server in the main office
and all branchs linked by (slow) ADSL connections (it's a very common
scenario here in Brazil), and he is talking about replication to have a
server at each branch that does a N-way sync to the others.


see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br