In general, you can get lock-like behavior using memcached atomic operations like incr, add and cas; for ideas, check out:
http://abhinavsingh.com/blog/2009/12/how-to-use-locks-for-assuring-atomic-operation-in-memcached/ http://terrychay.com/article/keeping-memcache-consistent.shtml On 9/17/10, subbu <subb...@gmail.com> wrote: > Hi, > > In our application, we are multiple application servers to fetch cache > data from memcached servers in cluster. > > Typical on first GET call the data is fetch from DB, converted to XML, > and put into memcached with a key. Their after any addition or > deletion are operated on XML by either removing a node or adding a > node and update record in DB tables. > > Now we are facing an issue. Since memcache client are running on > multiple application server. The user request to delete a node can > instated by any application in the cluster. > > In case we get multiple asynchronous multiple operation on same XML. > Each asynchronus client is trying to operate on the same XML data and > store back in memcache. ( see example below….) Which is resulting in > corrupting the XML since last operation / slowest client’s action is > finally stored in cache. > > Example [Using spymemcached Java client] > > Client1 ------fetch-- data [A,B,C,D,E] --- wants to delete node [A] > results in [B,C,D,E] > Client2 ------fetch-- data [A,B,C,D,E] --- wants to delete node [B] > results in [A,C,D,E] > Client3 ------fetch-- data [A,B,C,D,E] --- wants to delete node [C] > results in [A,B, D,E] > Client4 ------fetch-- data [A,B,C,D,E] --- wants to delete node [D] > results in [A,B,C, E] > > At end above cycle, it expected to have [E] in the XML. However, the > slowest or last to complete client’s modified XML goes into memcache, > hence result loss of data from remaining clients. > > Need DB kind of LOCK on “Write” so that each client actions are lost. > > Thanks, > Subbu >
