LISTEN/NOTIFY for lightweight replication

Hi,

I'm trying to come up with a relatively simple
multi-master replication solution. This is for
multiple databases that need to be discreet, and
change relatively infrequently (10-30 updates an
hour), and almost never update each others data (less
than once a day).

The TCL-based replication project for multi-master is
troublesome to configure and seems to really impact
performance. It can be assumed that the master-slave
setup will not work for me, nor do we want to purchase
a commercial soluton, nor can we run this all from one
central database.

I'm considering the following, and am requesting
advice and any suggestions:

a. Use listen/notify to develop a notification when
changes are made. This could be done between each
node, or not (i.e. it could be a chain instead).

b1. All of the add events are using sequences so each
node has a unique set of new records.

b2. When an add, update or delete is recorded, DDL of
this is passed via the notify.

c. If no local event happened prior during this event
envelope (i.e. since the last update notification but
before the new event completed), perform the event.

d. If there is a record level conflict but no field
level one, perform the event.

e. If there is a field level conflict, raise an
exception (TBD).

There are plenty of things that might not work here,
but I'm particularly interested in:

1. If this is brain-dead because of performance
issues, I'd like to know upfront.

2. Is there a way to get at the system tables that
would contain overall change events? Otherwise, is
this information available in some log event?

3. Can this be readily translated to DDL?

4. Does anyone have some extended examples of using
listen/notify, especially in any kind of distributed
transaction capability?

Thanks!

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail