Hi Chris, Chris Browne wrote:
I'm seeing some applications where it appears that there would be value in introducing asynchronous messaging, ala "message queueing." <http://en.wikipedia.org/wiki/Message_queue>
ISTM that 'message queue' is a way too general term. There are hundreds of different queues at different levels on a standard server. So I'm somewhat unsure about what problem you want to solve.
c) There are lesser names, like isectd <http://isectd.sf.net> and the (infamous?) Spread Toolkit which both implement memory-based messaging systems.
If a GCS is about what you're looking for, then you also might want to consider these: ensemble, appia or jGroups. There's a Java layer called jGCS, which supports even more, similar systems.
Another commonly used term is 'reliable multicast', which guarantees that messages are delivered to a group of recipients. These algorithms often are the basis for a GCS.
My bias would be to have something that can basically run as a thin set of stored procedures atop PostgreSQL :-). It would be trivial to extend that to support SOAP/XML-RPC, if desired.
Hm.. in Postgres-R I currently have (partial) support for ensemble and spread. Exporting that interface via stored procedures could be done, but you would probably need a manager process, as you certainly want your connections to persist across transactions (or not?).
Together with that process, we already have half of what Postgres-R is: an additional process which connects to the GCS. Thus I'm questioning, if there's value for exporting the interface. Can you think of other use cases than database replication? Why do you want to do that via the database, then, and not directly with the GCS?
It would be nice to achieve 'higher availability' by having queues where you might replicate the contents (probably using the MQ system itself ;-)) to other servers.
Uhm.. sorry, but I fail to see the big news here. Which replication solution does *not* work that way?
Regards Markus ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
