persistent fifo queue class

[Hendrik van Rooyen]

"David Bear" <da....bear at asu.edu> wrote:
> Diez B. Roggisch wrote:

> > Why don't you use a DB for that? If you want pickles, use a  blob
> > column. But all the rest - a defined protocol, stable server,
> > transactions - you get for free.
> > 
> > Diez
> 
> Thanks for the suggestion. I did think of this. Indeed the final destination
> of the data is in a db. However, the postsgresql server is on a separate
> box. It will be connected via a private lan. I was worried that possible
> network disruptions would cause either the web application to hang -- or
> data to just get lost. I was thinking along the lines is a message queue
> architecture, where the web app would push data directly onto a queue --
> and then a worker app would dequeue the data and handle it by sending it to
> the db server or otherwise.
> 
Have you looked at Pyro?

I think it could help to tie the boxes on the local LAN together,
with a 'Pusher' on the first box and a 'Popper' on the box where the 
final DB lives.  And Diez' DB could provide the persistence on the first
box.
The 'push' and 'pop' above are a bit of a misnomer, as Pyro will allow 
you to have a 'puller' on the final DB box to front end the DB.
I think a "double DB" architecture like that will be very robust as
Diez' DB can provide a "transactions queued, in process, and 
completed" log.

- Hendrik