[mysql-dde] Re: The mutual conflict problem

  • From: "Fabricio Mota" <fabricio.oliveira@xxxxxxxxxxxxxxxx>
  • To: <mysql-dde@xxxxxxxxxxxxx>
  • Date: Mon, 12 Dec 2005 14:49:58 -0200

Hey man,

And if we:

1) Keep such as a 'mailbox' that contains a pair indexname - indexvalue, for 
opened transactions.

Once the transaction is open, with a insertion of k to an index I, a pair 
I-k is inserted into this box. When the transaction is finished (aborted or 
commited), the item is removed.

This could ensure that no transaction will be 'violated', and the other 
servers could always check the index and the I-box to check about key 
violations or key intention to violate.

2) Stablish such as a order-priority among servers (maybe changeable along 
the time). That is: if Server Sa has a biggest priority than server Sb, when 
both agree to give priority to Sa.

So, if we optate to Check-Before-Insert (CBI) with Local Indexes, so when Sb 
request to Sa such as "Sa, is the value k existing for you?", Sa must verify 
both in index and in I-box.

But if we optate to Sync-After-Insert (SAI) with Global Indexes, so when Sb 
send to Sa such as "Sa, sync the pair k-Sb into your Global Index!", Sa must 
verify both in index and in I-box, before raises an exception "key violation 
with k" or ack it.

Hey, what do you think?

FM

----- Original Message ----- 
From: "Fabricio Mota" <fabricio.oliveira@xxxxxxxxxxxxxxxx>
To: <mysql-dde@xxxxxxxxxxxxx>
Sent: Monday, December 12, 2005 2:18 PM
Subject: [mysql-dde] Re: The mutual conflict problem


> Really, really... I must agree with you.
>
>
> But I still want to try suggesting another solution that does not depend 
> on
> a single master.
> I don't like no much this idea of a master.
>
> ----- Original Message ----- 
> From: "Peter B. Volk" <PeterB.Volk@xxxxxxx>
> To: <mysql-dde@xxxxxxxxxxxxx>
> Sent: Monday, December 12, 2005 1:01 PM
> Subject: [mysql-dde] Re: The mutual conflict problem
>
>
>> Ok I guess the list strips the images down:
>>
>> here are the links:
>>
>> www.inf.tu-dresden.de/~s7205538/dde/unique_management.jpg
>> www.inf.tu-dresden.de/~s7205538/dde/unique_management_sequenc.jpg
>>
>> Peter
>> ----- Original Message ----- 
>> From: "Peter B. Volk" <PeterB.Volk@xxxxxxx>
>> To: <mysql-dde@xxxxxxxxxxxxx>
>> Sent: Monday, December 12, 2005 3:56 PM
>> Subject: [mysql-dde] Re: The mutual conflict problem
>>
>>
>>> Hey,
>>> Well I could be solved by having GI-Key Masters. I've added 2 diagramms
>>> to
>>> show a few details.
>>>
>>> Peter
>>> ----- Original Message ----- 
>>> From: "Fabricio Mota" <fabricio.oliveira@xxxxxxxxxxxxxxxx>
>>> To: "dde" <mysql-dde@xxxxxxxxxxxxx>
>>> Sent: Monday, December 12, 2005 2:19 PM
>>> Subject: [mysql-dde] The mutual conflict problem
>>>
>>>
>>> > Hey Guy!
>>> > We have a problem with uniqueness management with any approach we use.
>>> That is:
>>> >
>>> > Suppose Clients C1 and C2, connected respectivelly through servers S1
>> and
>>> S2.
>>> > Both clients try to insert a value k, into a unique-indexed column.
>>> Suppose they try to insert the value approximately during the same time.
>>> >
>>> > If we think about to validate global uniqueness among servers before 
>>> > to
>>> insert, then:
>>> >
>>> > 1 - C1 tries to insert it through S1 / at same time, C2 tries it
>>> > through
>>> S2.
>>> > 2 - S1 validates k / C1 locally. Uniqueness is ok. S2 validates k / C2
>>> locally, too. Both are ok.
>>> > 3 - S1 request S2 about uniqueness of k. At aproximately the same 
>>> > time,
>> S2
>>> request the same for S1.
>>> > 4a - if we consider a fully isolated transaction approach, then S1 
>>> > will
>>> perform C1 command, and S2 will perform C2 command, too. That's an
>>> inconsistence!
>>> > 4b - if we consider the value k is shared during transactions, both
>>> servers will abort, because k is already there during remote validation,
>>> causing a mutual abort.
>>> >
>>> > If we think about to validate global uniqueness among servers after to
>>> insert, replicating global indexes, then:
>>> >
>>> > 1 - C1 tries to insert it through S1 / at same time, C2 tries it
>>> > through
>>> S2.
>>> > 2 - S1 validates k / C1 locally. Uniqueness is ok. S2 validates k / C2
>>> locally, too. Both are ok.
>>> > 3 - S1 tries to sync S2 about its new value k. At aproximately the 
>>> > same
>>> time, S2 tries to sync S1, too.
>>> > 4a - if we consider a fully isolated transaction approach, then S1 
>>> > will
>>> update S2 with its k, and S2 will update S1 with its own k, too. That's
>>> an
>>> inconsistence, again.
>>> > 4b - if we consider the value k is shared during transactions, both
>>> servers will abort, because k is already there during remote validation,
>>> causing a mutual abort.
>>> >
>>> > If we consider the hypothesis 4b, what criterion could be used for 
>>> > both
>>> server to agree in which transaction to abort?
>>> >
>>> > Or so, what could we do in respect to it?
>>> >
>>> > Fabricio Mota
>>> > Analista de Sistemas
>>> > FCPC - Divisão de Planejamento do Cadastro Comercial
>>> > MySql-DDE discussion list
>>> > www.freelists.org/
>>> >
>>>
>>>
>>>
>>>
>>> MySql-DDE discussion list
>>> www.freelists.org/
>>>
>>
>> MySql-DDE discussion list
>> www.freelists.org/
>>
>>
>
> MySql-DDE discussion list
> www.freelists.org/
>
> 

MySql-DDE discussion list
www.freelists.org/

Other related posts: