Assuming that ID is the primary key...
Case #1 - the end result would be that both operations succeed in the replicat. So Site B would end up having 5001110000 and Site A would end up having 600011110000. OGG, by default, only uses the primary key (OR KEYCOLS) columns in the where clause. Since the key is not changing and the UPDATE operation is executed successfully, what ends up happening is that both operations succeed.
Case #2 - the result is the same here as in case #1. Since the PK is the only value used in the where clause, both operations would be applied successfully.
1) if you want a conflict to be triggered here, you can do two things, you can use COMPARECOLS to include all columns, and that forces the WHERE clause to include the NUMBER and ADDRESS columns as well as the ID column (primary key) and then the RESOLVECONFLICT portion of the MAP statement would kick in and you can use that to handle the conflict.
2) Depending on the COMPARESCOLS settings and RESOLVECONFLICT settings, yes, you can get this to occur quite easily, where both succeed, however, you can also configure it so that one system overrides another.
I would recommend reading up on the Active-Active white paper. It's here:
Thanks Nick. A bit more clarification needed.
You said "Case #2 - the result is the same here as in case #1"
But GETBEFORECOLS and COMPARECOLS will have to be configured here for all columns if I want case 1 to trigger conflict. In that case even if different columns are being updated, there will be a conflict since the trail has before images of all the columns.
My question is, how can I configue GG so that case 1 triggers conflict AND case 2 doesnt.
I hope you got what I'm trying to say.
To get Case 1 to trigger and case 2 not to trigger, then that is configured in the COMPARECOLS section.
Your COMPARECOLS would not include the NUMBER and ADDRESS fields and would only contain the ID and timestamp column.