[jbosscache-dev] JBoss Cache 2.0.0.ALPHA status

[Brian Stansberry]

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 at 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