persistent fifo queue class
Hendrik van Rooyen
mail at microcorp.co.za
Thu Mar 8 07:24:59 CET 2007
"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
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
More information about the Python-list