Hmm..looked at gearman and beanstalkd. I'm not sure I actually have a queuing problem. Service A wants to use Service B as a "database" but doesn't want to go over the wire with an RPC call every time it accesses Data Unit X (which only changes rarely). Yes, Service B will know when Data Unit X changes, and yes I can do it the other way around and have Service B generate an update message when it changes Data Unit X, but it still seems like a queue or a message bus is overkill.
On Oct 29, 2:37 pm, "Josef Finsel" <[EMAIL PROTECTED]> wrote: > The short answer is no. > Memcached is a cache. > > What you want is a queue, and if you do a quick scan of the list archives, > you'll find there was a good discussion of this topic > (http://groups.google.com/group/memcached/browse_thread/thread/6e1c7f1...)<http://groups.google.com/group/memcached/browse_thread/thread/6e1c7f1...> > > On Wed, Oct 29, 2008 at 3:31 PM, outinsun <[EMAIL PROTECTED]> wrote: > > > I am building an application using SOA. I have one service that needs > > to embed infrequently updated information that is managed by another > > service. I want to avoid having to make RPC calls every time I access > > the data in question, but also want to make sure updates to that data > > are reflected at the other end. I can't figure out whether memcached > > is a logical basis for this kind of application, or is completely > > irrelevant. Any thoughts? If irrelevant, any pointers to something > > more appropriate? > > -- > "If you see a whole thing - it seems that it's always beautiful. Planets, > lives... But up close a world's all dirt and rocks. And day to day, life's a > hard job, you get tired, you lose the pattern." > Ursula K. Le Guin > > http://www.finsel.com/words,-words,-words.aspx(My blog) > -http://www.finsel.com/photo-gallery.aspx(My Photogallery) > -http://www.reluctantdba.com/dbas-and-programmers/blog.aspx(My Professional > Blog)
