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.