[mysql-dde] Re: The mutual conflict problem

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

Still other problem:

Both to my suggestion and to yours, we must consider that:

If Server Sa has the priority (no matter by what manner it's stabilished), 
and if Sb knows to be deferred, then it must block its transaction and wait 
for the end of Sa transaction. Do you agree?

That's because: if we notice Sb with "key violation message", and Sa, istead 
of commit, rolls back??
We will get the same problem of mutual abort.

FM

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


> 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: