That is a caching problem, since the worst case the data is lost and you make too many service calls. As long as it is acceptable to lose data as it can be recreated, then a cache like memcached works quite well.
In our SOA environment, we have something similar to what you want. The service definition may opt-in to support near caching (in-memory + memcached) where a miss invokes the service. At the service's side, it may also be using the caching layers where a miss invokes the database. Since the services most likely reside on different functional clusters, we've been using only expiration for near caching rather than having to broadcast the invalidation message across clusters. This works pretty well for services where eventual consistency is acceptable. ________________________________ From: outinsun <[EMAIL PROTECTED]> To: memcached <[email protected]> Sent: Wednesday, October 29, 2008 1:00:11 PM Subject: Re: Is memcached the right tool for inter-service synchronization? 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)
