if you have an end user (sure hope you do), does the end user want

a) to have to wait for all databases to be up to place an order
b) to just have their database up to place an order?

does the end user want to wait for

a) a local transaction and remote transaction to take place, along with the mandatory two phase commit or...
b) a local transaction with a simple commit

can the database you are replicating into or consolidating into handle

a) its load PLUS all of the load from the other machine or...
b) its load PLUS a "manageable, controllable flow of data from the other machine"


It would be more fair to say that MQ is like AQ yes. MQ is a stripped down db2 database used as a stable store (it is a database, needs to be backed up, recovered and so on -- but you cannot use it as a database, so it is yet another cog in the machine to manage). AQ provides a message queue inside the database -- the database you are problably already transacting against in the first place.


It is all about providing to the end user a more available, apparently faster, more reliable place to do their work. Slow things happen in the background, failures of systems are tolerated -- expected even, but gracefully dealt with.

this conflict occurrs BECAUSE two transactions can take place against the same logical data at precisely the same point in time (time delay is not the factor in as much as "we are asyncronous").

AQ is a foundation technology.
AQ cannot be used to "avoid this"

Only SYNCRONOUS replication (we update both locations in the same transaction) or rules that prevent the same bits of data being updated in more than one location at a time are able to "prevent" this.

AQ can propagate as fast as you like, time has no bearing on this at all. In a split instant you have update conflicts -- I'll update "where x=5" on site 1 -- you update "where x=5" on site 2 -- at the same instant. No time delays involved.

replication -- we use it there.

you see it here on asktom. true, I use dbms_jobs as a poor mans AQ but it is precisely the same concept. When I do stuff, it generates a message (a job). That message -- "document=4321432143 was modified, notify interested parties". The database I'm replicating to? SMTP -- I send an email, after I commit.


robust database to database plain old data example -- replication. done. lots of examples/documentation on that. AQ is the building block (not the end solution, an enabling technology).

that just described replication to a tee

(1) and (2), we call that "replication"


but if you just want to tell database 2 'hey, database 2, this is database 1, we just did "X", if you care -- do something about that fact'

then your picture applies just as well.


Think of AQ just like you think of EMAIL (that is what it is with lots of fancy stuff).

If you were to send email to me, what happens?

a) you perform a local transaction of compose email and send to your smtp server (the database) and commit. If my system is up or down -- you don't care. If your network to the outside world is up or down -- you don't care. The only thing that needs to be up is your database (smtp server)

b) after you commit (give the email to your smtp server), it will try to relay it to me. If the network is down, it'll keep trying. If the network send fails partway through the send, it'll retry it later. Eventually the message gets to my system.

c) I read it and act on it (doing whatever..)


That describes AQ as well. Just "store and forward", just messages. You can build whatever you like on top of it.


But your picture looks suspiciously like "replication" to me -- eg: STREAMS -- it does all of the above and if you want to do the update yourself, streams could call you (eg: you need only write the "apply" routine on database 2)