Thought about it a bit more, and I don't think it has that problem. If the remote cache is being used as a cacheloader, it should have no existence other than for that purpose. So, a store call should feel free to completely replace the subtree being stored. Therefore, the first step of the state transfer store should be to recursively remove all nodes for the given subtree in the remote cache. Thereafter there are no problems with leftover data. Vladimir Blagojevic wrote: > This approach would be a very nice and generic solution but as you > point it has a problem with integration/clearing of nodes. > > Looks like we have to do something along the lines that Manik > suggested. I'll assign that task to myself. > >> -----Original Message----- >> From: Brian Stansberry >> Sent: Monday, September 11, 2006 12:35 PM >> To: Vladimir Blagojevic; Manik Surtani; >> jbosscache-dev(a)lists.jboss.org Subject: RE: [jbosscache-dev] JBoss >> Cache 2.0.0.ALPHA status >> >> Vladimir Blagojevic wrote: >>> I made TcpCacheLoader test pass but tcpcacheloader will not >>> propagate load/store. This was the case even before I made the >>> cacheloader change. Similar situation is with rpc and rmi loaders >>> and we have to figure out what to do there. >> >> In the case of store, is this a matter of reading out the NodeData >> objects and invoking a put(Fqn, Map) on the remote cache for each >> one? For load, a bunch of recursive get(Fqn) calls to create the >> NodeData? (I'm skipping any subtleties of the 2.0 API here.) >> >> A problem with the put(Fqn, Map) approach is that call integrates >> the passed Map into the target node, rather than replacing the map >> contents. So you could be left with stale key/value pairs in the >> far cache. Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat Ph: 510-396-3864 skype: bstansberry _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev