William Yu <wyu@xxxxxxxxxxx> writes: > David Goodenough wrote: >> The most obvious one that does exactly this (generic multi-master >> replication) is Lotus Domino. It is not a relational DB, but not sufficiently >> far off to stop the analogy. >> Domino marks each document with a binary value which identifies the >> server (built from a hash of the server name and the time the DB was >> created) and a timestamp when it was last modified, and also each document >> (record) has an ID (like OIDs). More recent versions also do this at a field >> level to avoid conflicts and speed replication. When two servers replicate > > This system sounds ok for documents and general data that can always > be revived via version control/history. But I can't see how this > would work for financial transactions where you're dealing with > money and bank accounts. Suppose I have $100 in my account. I > decided to login to multiple servers and wire transfer $100 to > another account on every server. And I hit submit exactly at the > same time for every server so check. Sure they can resolve the > conflict afterwards in terms of saying in terms of which transfer to > kill off. But the fact is that my other account has that N x $100 > already and I've just fleeced the bank. There are two pretty reasonable ways to address this: 1. Your application does not replicate balances; those are always computed locally. Only *transactions* are relayed. 2. Balance updates take place as a special kind of "delta update" where replication transfers around (old.balance - new.balance) instead of either of the values. Either of these leads to the nifty case where that bank discovers that you have overdrawn your account, and then takes whatever actions they deem are appropriate next. Such as billing you $29 for each overdraft transaction. You're hardly going to be retiring to the Bahamas on Nx$100, are you :-). -- select 'cbbrowne' || '@' || 'ntlug.org'; http://cbbrowne.com/info/internet.html Rules of the Evil Overlord #211. "If my chief engineer displeases me, he will be shot, not imprisoned in the dungeon or beyond the traps he helped design." <http://www.eviloverlord.com/> ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
