Re: 2 way replication?

From: Christopher Browne <cbbrowne_at_cbbrowne.com>
Date: Mon, 26 May 2003 22:35:57 -0400
Message-ID: <m365nxi0aa.fsf_at_chvatal.cbbrowne.com>


In an attempt to throw the authorities off his trail, "Walter L. Preuninger II" <walterp_at_texramp.net> transmitted:
> I understand the confusion when an update occurs on B and C to the same
> record. In my application, simultaneous updates should not occur on B and C
> within a predefined time window.

What precisely do you mean by "should not occur?"

Do you mean that you if it occurs, that is an error condition you don't expect to be able to cope with? Or that you wish there were a way to prevent concurrent updates? Or that you have some means to prevent it, and thus need not worry about it?

Those are all different scenarios...

> Is there a free database that supports this. I have read up on
> postgres and find no reference to 2 way replication.

This is _really_ troublesome, for _any_ sort of system, because there's lots of tough-to-replicate state involved. Simple examples would include:

 -> Concurrent updates to the same record

    Which you pointed out

 -> Creation of conflicting records

    I occasionally see minor "hiccups" with PG replication that result     when two servers try to create records with the same unique key     value with transactions with concurrent context. The system can't     know the values conflict until both transactions COMMIT...

    If you have a "sequence" system as with PostgreSQL CREATE     SEQUENCE, or, for that matter, anything analagous, the internal     state that manages the sequence is something that needs to get     distributed.

If you're really in need of a distributed processing system, it seems to me that you maybe need to look to having some sort of distributed transaction middleware that is the _real_ coordinator of the updates.

The more powerful your DBMS is, the more challenging it will be to have the desired semantics, and I'm not sure it is realistic to get what you seem to think you want.

Having all the systems be "masters" seems unlikely to be able to work...

-- 
output = reverse("gro.gultn" "_at_" "enworbbc")
http://www.ntlug.org/~cbbrowne/rdbms.html
Never  knock on  Death's door;  ring the  doorbell and  run  (he hates
that).
Received on Tue May 27 2003 - 04:35:57 CEST

Original text of this message