On 8/23/07, Mark Knoop <[EMAIL PROTECTED]> wrote: > > Don't use a DB as the backing store for a message queue if you will ever > > need to pass a lot of messages thought it - you're just asking for > > trouble doing it that way. > > > > Getting way off topic but, understanding the kind of trouble one can get > into using a DB to store messages, how else can one ensure data is always > recoverable should the app bomb out? >
That's why one normally doesn't implement a message queue from scratch, but instead uses an off the shelf one (same deal as databases). Message queueing systems vary (again, much like databases) in what features they support. Reliable messaging transactions, or just "best effort"? Local-only, or networked? Disk-backed, or memory-only (are messages lost if they machine randomly reboots)? Single-hop messaging events, or does the system actually track larger-scale transactions that encompass several different queued messages between different components over time? If transactional, does it integrate with your database's transaction system? Can messages only have one receiver, or can they be multicast/broadcast? To give some idea, here's a couple of common products in the commercial world: IBM's MQSeries (now called WebSphere MQ) http://www-306.ibm.com/software/integration/wmq/features/ BEA MessageQ: http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/more/messageq If you search CPAN Distributions for the word Queue, you get 35 hits that range all over the feature map for a queuing system, including interfaces to some of the commercial systems. -- Brandon _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/