Subject Re: [Firebird-Architect] RFC: Clustering
Author Alex Peshkov
= m. Th =:
> Alexandre Benson Smith wrote:
>> = 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 ?
>>
>>
> Yes. Basically, let's keep in mind that "a cluster is a virtual
> computer". In deed, we have three nodes N1, N2, N3. The client will send
> the command to each node on a separate thread (with, perhaps, different
> execution speeds) but a commit or rollback will be done in sync IOW, all
> the other threads will wait for the slowest thread to terminate (either
> successfully either with a 'host not found' error). Doing a separate
> commits/rollbacks will break the atomicity and the "virtual computer"
> will be a image broken in a thousand pieces.
>


Such mode has one severe problem. Generators. Assume (for simplicity)
that we have 2 clients and 2 nodes. In database we have generator G1,
table T1 with unique PK column C1 and before insert trigger, doing the
following:
C1.NEW = GEN_ID(G1, 1);
Both clients perform INSERT INTO T1 ..... Packet from Client1 first
reaches N1, but from Client2 - N2. As the result, record added by
Client1 will have C1 == 1 at N1 and C1 == 2 at N2. As soon as you want
to reference that record using FK, you will have a lot of problems.