Re: Efficient way of global concurrency control/serializability in federated databases??
From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 09 Oct 2006 03:32:07 GMT
Message-ID: <XojWg.110479$1T2.100979_at_pd7urf2no>
> Let me stick my neck out on this one, based on what was possible ten
> years ago, but I doubt anything brilliant has come along since then,
> except maybe for pathological cases.
>
> Regardless of whether you wanted to apply update a to db A and update b
> to db B, C et cetera or whether update a was to be applied to db A and
> B, a so-called two phase commit protocol was needed. Ie., anything
> other than that would risk a being applied and b not being applied and
> vice versa, which would require that manual intervention always be
> available. One db is the coordinator, it sends two messages to all the
> other dbs, first is the update along with the question - do you promise
> to commit this if I send a second message. If all the respondent dbs
> answer yes, then the coordinator sends each of them a second message
> telling them to go ahead. If the coordinator fails in the meantime, its
> own undolog will tell it on the next startup to tell the other dbs to
> undo their own commits. ...
Date: Mon, 09 Oct 2006 03:32:07 GMT
Message-ID: <XojWg.110479$1T2.100979_at_pd7urf2no>
paul c wrote:
> anonym wrote:
>> Hi, >> >> I am preparing an analysis report and need some help. >> Currently, what is the most efficient / most used way of ensuring >> global concurrency control / serializability in federated >> databases/multidatabases ?? Thank you. >>
> Let me stick my neck out on this one, based on what was possible ten
> years ago, but I doubt anything brilliant has come along since then,
> except maybe for pathological cases.
>
> Regardless of whether you wanted to apply update a to db A and update b
> to db B, C et cetera or whether update a was to be applied to db A and
> B, a so-called two phase commit protocol was needed. Ie., anything
> other than that would risk a being applied and b not being applied and
> vice versa, which would require that manual intervention always be
> available. One db is the coordinator, it sends two messages to all the
> other dbs, first is the update along with the question - do you promise
> to commit this if I send a second message. If all the respondent dbs
> answer yes, then the coordinator sends each of them a second message
> telling them to go ahead. If the coordinator fails in the meantime, its
> own undolog will tell it on the next startup to tell the other dbs to
> undo their own commits. ...
sorry, i should have said to tell the respondents not to apply their PENDING commits. i got it all balled up just like i used to when i hated doing this stuff! now i cannot remember whether undo by the coordinator was essential, maybe it was that as long as the respondents had a start-up failsafe scheme, they would always re-apply any update that got lost.
p Received on Mon Oct 09 2006 - 05:32:07 CEST